Syntactically rejecting impl-Trait inside non-final path segments & inside fn ptr types is futile

[fmease]

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 lowering (since #132214)).
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¹.
Therefore we can simply circumvent them by introducing indirection via type aliases.

Examples:

fn proj_selfty_e_neg() -> <impl Sized as Mirror>::Image {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn proj_selfty_e_pos() -> MirrorImage<impl Sized> {} // 🟢 Workaround: ACCEPTED

fn proj_selfty_u_neg(_: <impl Sized as Mirror>::Image) {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn proj_selfty_u_pos(_: MirrorImage<impl Sized>) {} // 🟢 Workaround: ACCEPTED


fn qself_trait_u_neg(_: <() as Carry<impl Sized>>::Project) {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn qself_trait_u_pos(_: Project<impl Sized>) {} // 🟢 Workaround: ACCEPTED


// <> under `#![feature(inherent_associated_types)]` only
fn non_final_seg_u_neg(_: Transp<impl Sized>::InhProject) {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn non_final_seg_u_pos(_: InhProject<impl Sized>) {} // 🟢 Workaround: ACCEPTED
// </>


fn fn_ptr0_e_neg() -> fn() -> impl Sized { || {} } // 🔴 REJECTED: `impl Trait` is not allowed in `fn` pointer return types
fn fn_ptr0_e_pos() -> FnPtrOut<impl Sized> { || {} } // 🟢 Workaround: ACCEPTED

fn fn_ptr1_e_neg() -> fn(impl Sized) { |()| {} } // 🔴 REJECTED: `impl Trait` is not allowed in `fn` pointer parameters
fn fn_ptr1_e_pos() -> FnPtrIn<impl Sized> { |()| {} } // 🟢 Workaround: ACCEPTED

fn fn_ptr_u_neg(_: fn(impl Sized)) {} // 🔴 REJECTED: `impl Trait` is not allowed in `fn` pointer parameters
fn fn_ptr_u_pos(_: FnPtrIn<impl Sized>) {} // 🟢 Workaround: ACCEPTED

//////////////////////////////////////////////////

trait Mirror { type Image; }
impl<T> Mirror for T { type Image = T; }
type MirrorImage<T> = <T as Mirror>::Image;

trait Carry<T> { type Project; }
impl<T> Carry<T> for () { type Project = (); } 
type Project<T> =  <() as Carry<T>>::Project;

// <> under `#![feature(inherent_associated_types)]` only
struct Transp<T>(T);
impl<T> Transp<T> { type InhProject = (); }
type InhProject<T> = Transp<T>::InhProject;
// </>

type FnPtrOut<O> = fn() -> O;
type FnPtrIn<I> = fn(I);

---

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 in fn_ptr0_e_neg) but a lot of them are not at all what you want. Some of them are completely useless (by containing unredeemably uninferable types). I don't think any of them lead to soundness issues.

Footnotes

1. They could've been syntactic modulo (eager) type alias expansion (≠ normalization). ↩

[fmease]

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.