Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the Trait<Output=Type> syntax #18432

Closed
nikomatsakis opened this issue Oct 29, 2014 · 5 comments · Fixed by #19391
Closed

Support the Trait<Output=Type> syntax #18432

nikomatsakis opened this issue Oct 29, 2014 · 5 comments · Fixed by #19391
Assignees

Comments

@nikomatsakis
Copy link
Contributor

Today when we expand associated types we always expand to a fresh type parameter. Per the RFC we should support a syntax like:

Trait<Output=Type>

to permit a trait reference that specifies what to expand an associated type into. This is a subset of full == references.

Note that cyclic equality does not have to be supported (though it'd be nice if it at least produced a nice error message, not an ICE):

fn foo<T:Something<Out=U::Out>, U:Something<Out=T::Out>>() { ... }
@nrc nrc self-assigned this Nov 5, 2014
@nrc
Copy link
Member

nrc commented Nov 6, 2014

To clarify the specification here, there are two ways to use an equality bound (afaiui) - in where clauses and as a type parameter. E.g.,

trait Foo {
    type A;
}

struct Bar;

fn foo<I: Foo<A=Bar>>(x: &I) {}

fn foo<I>(x: &I)
    where I: Foo,
          I::A = Bar
{
}

The two definitions of foo are equivalent.

@nrc
Copy link
Member

nrc commented Nov 6, 2014

The 'parameter' form also allows such bounds on trait objects, e.g., &Foo<A=Bar>.

@nikomatsakis
Copy link
Contributor Author

Yes, though this issue is specific to the Foo=Bar form, which avoids some complexities that the other form admits. (In particular, things like fn foo<A,B>() where A = B). You could (I guess) support a limited form of constraints like X::E = Y (though note that X::E is not legal syntax yet; supporting that is a separate issue).

@nrc
Copy link
Member

nrc commented Nov 17, 2014

@nikomatsakis clarifying: the two forms you are discussing are A=Foo and I::A=Foo? Both in where clauses (the <A=Foo> form being sugar for where I::A=Foo). Or are you suggesting only implementing the <A=Foo> form and not any equality constraint inwhere clauses?

@nikomatsakis
Copy link
Contributor Author

@nick29581 sorry, missed that message, I was suggesting only implementing A=Foo and not any equality constraints, since it is more general (works for object types) and covers only the range of constraints we want, but I have no objection to doing more. Anyway, I see you have a PR now, so I guess this is moot.

bors added a commit that referenced this issue Dec 12, 2014
r? @nikomatsakis 

cc @aturon (I think you were interested in this for some library stuff)

closes #18432
bors added a commit that referenced this issue Dec 12, 2014
r? @nikomatsakis 

cc @aturon (I think you were interested in this for some library stuff)

closes #18432
lnicola pushed a commit to lnicola/rust that referenced this issue Nov 4, 2024
fix: Fix the server not honoring diagnostic refresh support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants