Tracking issue for non_static_type_id

[eddyb]

This is a tracking issue for the RFC "1849" (rust-lang/rfcs#1849).

Steps:

• Implement the RFC
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

[eddyb]

Implementation instructions:

• remove the 'static bound from the type_id intrinsic
• add more cases to the typeid-intrinsic test:
  • in a function that has an 'a parameter and uses 'a in types
  • should check that non-'static lifetimes are allowed
  • also that they are ignored (e.g. &'a Foo and &'static Foo have the same type_id)

I'd like to participate on this :)

[eddyb]

@z1mvader Great! Don't forget to put "r? @eddyb" in your PR when you open it.

[fcofdez]

Is someone working on this issue? I would like to help with it.

Hi, I'm currently working on it. I'm working on the tests

[kennytm]

Could std::error::Error::{is, downcast_ref, downcast_mut} relax the 'static bound as well?

These currently require the 'static bound due to TypeId, and this makes it impossible to inspect the cause(), which just returns an Option<&Error> without 'static bound.

cc #35943

[eddyb]

@kennytm Those sound like they do the same thing as Any, in which case relaxing them is unsound (see comments on rust-lang/rfcs#1849 for some more details).

[kennytm]

@eddyb Thanks, I misread RFC. Sounds like doing this soundly will require &'a T and &'b T to encode to different TypeId, which is not possible because lifetime is not encoded in trans.

[eddyb]

Not exactly. Lifetimes are a bit... "infinite" in their multitude.

What you want (like I mentioned in the RFC comments) is a scheme to specify where each of N lifetimes go (e.g. Foo<'a> = &'a T for one lifetime), enforce that there are no other lifetimes (e.g. Foo<'static>: 'static), encode that in a TypeId (e.g. for<'a> fn(Foo<'a>) - note that this is 'static and the for<'a> is preserved), then have one Any-like trait for every number of lifetimes (e.g. out of Box<Foo<'a>> you create Box<Any1<'a>>) and a way to downcast by providing the constructor (Foo *not *Foo<'something>).

This scheme requires HKT/ATC or even messier generic traits with HRTB. The main downside is the manual impls necessary without some kind of type lambda.

[Aceeri]

@z1mvader Are you still working on this?

i thought @kennytm was. I no longer have time sorry :(