You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just like the other known "missing WF checks" bug (#21903):
typeFoo = Vec<dynCopy>;
Unlike type aliases, I don't believe you can even reach the type written in the where clause without any bounds, since it doesn't even "remain in the type/trait-system" (e.g. inference can't pick it up).
So it's not as bad, but I did come up with use for it as a WF requirement, in #44580 (comment).
Activity
where Type:,
into a WF(Type) predicate, instead of ignoring it. #53707Auto merge of #53707 - eddyb:phantom-waffles, r=<try>
Centril commentedon Aug 27, 2018
Why is
fn foo() where Vec<dyn Copy>: {}
even passing the parser?There is no bound on the RHS of
:
...cramertj commentedon Aug 27, 2018
@Centril We're pretty permissive with parsing "zero or more" of many syntax elements, e.g.
fn foo() where {}
also compiles.Centril commentedon Aug 27, 2018
@cramertj Oh I see; that's where this is coming from. It didn't click initially; Thanks! ❤️
Centril commentedon Aug 30, 2018
We discussed this briefly on the meeting and the consensus was that if crater passes, then this is fine.
eddyb commentedon Sep 5, 2018
This is waiting on @nikomatsakis or someone else r+'ing #53707 (crater was clean).