-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Allow generic associate types in trait paths #67510
Comments
I'll take at least the ast part of it for now |
Am I correct in that we don't accept any type bounds on the left hand side and suggest moving them into a |
Do you mean is |
We allow repeating bounds in impl blocks though, i.e. this is permitted currently
Edit: thinking about it, we probably wouldn't be able to do it even if we want to because we can't parse where clauses anyway |
Is this still being handled? I am willing to look into it myself, I am currently stuck on needing this feature (and admittedly have a lot of time on my hands with recent events). |
@SuperTails You are welcome to take it, Im busy with chalk work atm |
I found another case where this is needed: I have a trait definition which looks like this: pub trait ViewFn<S> {
type Output<'ast>: Sized;
fn view<'ast>(&self, node: &'ast S) -> Self::Output<'ast>;
// ...
} If I want to have a trait bound on /*[...]*/<T, O, F>/*[...]*/
where
O: // omitted [...]
F: ViewFn<T, for<'x> Output<'x> = &'x O>, |
Is this a duplicate? I copied this from the RFC. Playground. trait StreamingIterator {
type Item<'a>;
fn next<'a>(&'a mut self) -> Option<Self::Item<'a>>;
}
fn foo<T: for<'a> StreamingIterator<Item<'a> = &'a [i32]>>(iter: T) { unimplemented!() } |
@vandenheuvel I think that is the same issue, yes. |
Some thoughts:
The From that we see that the associated type constraint syntax is really ambiguous with generic type parameters, but also get a clue on how to approach it during parsing.
for<'a> Trait<A<'a> = &'a u8> , so we don't have to introduce any new syntax for the name introducer like Trait<for<'a> A<'a> = &'a u8> (The only question is whether these two forms can be considered equivalent, it seems like yes.) |
personally I would prefer Trait<for<'a> A<'a> = &'a u8> (about the alternative:) I just wonder what would happen if it may clash, like: for<'a> X<'a>: Trait<A<'a> = &'a u8> vs. for<'x> X<'x>: Trait<for<'a> A<'a> = &'a u8> I think we should allow both syntax '(es), which should be considered equivalent in simple cases, but may be able to express more complex relations cleanly. |
The |
…-trait-paths, r=jackh726 Generic associated types in trait paths This is the second part of rust-lang#78978 This should fix: Fixes rust-lang#67510 Fixes rust-lang#68648 Fixes rust-lang#68649 Fixes rust-lang#68650 Fixes rust-lang#68652 Fixes rust-lang#74684 Fixes rust-lang#76535 Fixes rust-lang#79422 Fixes rust-lang#80433 and implement the remaining functionality needed for rust-lang#44265 r? `@matthewjasper`
Edit: Seems it's just impossible to instantiate something with one of these bounds in general? It seems that gat equals gat equality doesn't work, i.e.: <A, B>
A: Gat,
B: for<'x> Gat<Domain<'x> = A::Domain<'x>>, When you try to use something which uses the However the following (and other infinitely many variations) do work: <A, B, T>
A: for<'x> Gat<Domain<'x> = T>,
B: for<'x> Gat<Domain<'x> = T>, <A, B, T: ?Sized>
A: for<'x> Gat<Domain<'x> = &'x T>,
B: for<'x> Gat<Domain<'x> = &'x T>, I think the first bound should cover both the second and third cases, or am I missing something? |
The following code should be accepted:
The text was updated successfully, but these errors were encountered: