Open fmease opened 4 hours ago
And yes, one could argue that some of these forms that make use of type aliases would not be semantically equivalent to their "unaliased" counterpart in a hypothetical future version of Rust (similar to how type aliases are already referentially opaque if they are TAITs).
The only example I can think of right now is -> FnPtrIn<impl Sized>
vs. -> fn(impl Sized)
where impl Sized
would always be interpreted as existential in the former case (like it is today) and interpreted as "universal" in the latter case (*for<T> fn(T)
, APIT for fn ptr tys) with the caveat that we might never actually (want to) support the latter form (and therefore keep rejecting it as we do today). So it would only ever be "universal" in spirit and reserved indefinitely.
This concerns both universal and existential impl-Trait.
Since #48084 (2018) we reject impl-Trait inside qselves and non-final path segments (during AST validation). Since #45918 (2017) we reject impl-Trait inside fn ptr types (during AST lowering).
However, both checks are purely syntactic / syntax-driven as they happen before HIR analysis[^1]. Therefore we can simply circumvent them by introducing indirection via type aliases.
Examples:
This calls into question the very existence of these checks.
Should we just remove them? Are they historical remnants? Or should we keep them to prevent users from shooting themselves into the foot? Some of these types are actually quite useful (e.g., the
fn() -> impl Sized
as seen infn_ptr0_e_neg
) but a lot of them are not at all what you what. Some of them are completely useless (by containing unredeemably uninferable types). I don't think any of them lead to soundness issues.[^1]: They could've been syntactic modulo (eager) type alias expansion (ā normalization).