Why the `'_` cannot be used in associated type

language design
1

For example, suppose I have a trait 'MyTrait' with associated type 'MyType'.

trait MyTrait {
  type MyType;
  fn get(&self) -> impl Deref<Target = MyType>;
}

And I probably want to implement something like:

struct Something(u64);
impl MyTrait {
  type MyType = &'_ u64;
  fn get(&self) -> impl Deref<Target = MyType> {
    &&self.0
  }
}

Why the community decided to adopt GAT instead of this?

2

&'_ u64 is not a type. It's containing an elided lifetime.[1] Elision is a mechanism to cut down on verbosity for common patterns of code generic over lifetimes. For this, there are elision rules that desugar all elided lifetimes into code with all lifetimes explicit.

For your proposed syntax to make sense, you'd have to explain the elision rules that desugar the syntax into

You can't implement MyTrait using &'_ u64 as MyType because MyType by the definition of that trait doesn't have any generic lifetime generic arguments (nor does the trait itself). There is no possible desugaring that can make sense. Generic associated types are adopted because you need a generic lifetime argument to have a lifetime. (Or the lifetime could be 'static, but that's not really a solution in this use-case.)

Also, your example code is confusing for a motivating example, because you're returning a reference to a local temporary (&self.0 is a re-borrow of the &self argument, and &&self.0 is a reference to that re-borrow, thus you can't actually return this from a function).

  1. In certain context, e. g. types used within function bodies, the same syntax can also instead mean an inferred lifetime. ↩ī¸Ž

5 Likes