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)

[bluss]

Agreed, and that's a problem because there is no way to write that restriction as a where clause on a function, like for example fn type_equals<T, U>() -> bool; For example I'd start with exactly where U: 'static, but as you say, it's not enough to lead to soundness. I'd only use it in unsafe code where I could verify myself that the input to U would be lifetime free.

[Avi-D-coder]

Even here - yes, it would be wrong to compare &f64 and &'static f64 for "type equality", but that's not a needed feature in this use case.

@bluss why is it wrong, to compare &f64 and &'static f64, according to the RFC they will always have the same TypeId, since lifetimes are erased.

[bluss]

If I understand correctly, it would be an ok verdict from the function itself, it's just dangerous if users act on it, for example, you might assume that if two types are equal (according to that comparison), then you can freely cast a raw pointer to one to the other type, and this breaks down with types that have lifetimes.

[Avi-D-coder]

I think part of the problem with the conversation in this issue is we all mean slightly different things by type equality, wrong, safe and unsound.

If a cast is made as a result of the erroneous belief that TypeId equality implies lifetime equality, then I would say the cast is wrong/unsound not the TypeId comparison. And I might say type equality has been established, dispite the lack of lifetime equality.

While this feature clearly can be a foot-gun. The solution is to document that TypeId is blind to lifetimes rather than undoing the RFC. The ability to compare lifetime erased types is very useful to me, and the various workarounds are not general purpose. The confusion about and various unsound uses of this feature, could very well be a result of not reading the RFC, since the docs don't mention lifetime erasure at all.

If this feature were added to nightly with updated doc I don't think there would be very much confusion.

[joshtriplett]

@rfcbot cancel

[rfcbot]

@joshtriplett proposal cancelled.

[joshtriplett]

@rfcbot close

[rfcbot]

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:

• [x] @cramertj
• [x] @joshtriplett
• [x] @nikomatsakis
• [ ] @pnkfelix
• [x] @scottmcm
• [ ] @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[nikomatsakis]

It's probably worth adding a bit of context here. We discussed this in our recent @rust-lang/lang team meeting and the general feeling was that this feature just felt like it wasn't adding enough value, given the potential for confusion and misuse.

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[nikomatsakis]

I don't believe this was ever implemented. I have pushed an update to the RFC indicating it was retracted. I'm going to close the tracking issue now.

[dtolnay]

I put up a pre-RFC in https://internals.rust-lang.org/t/pre-rfc-non-footgun-non-static-typeid/17079 with a counterproposal that unblocks many of the use cases that wanted non-'static TypeId, but in a way that does not open up the risks that have been discussed above in this issue.

[eddyb]

There was one usecase which came up early on IIRC, that wouldn't be solved by the "dynamic conservative : 'static check" shenanigans, which was something like TypeId::of::<Foo<'a>>() being used as a workaround TypeId::of::<FooTag>().

Nevertheless, I'm extremely wary of anything allowing actual lifetimes in there, compared to only doing the : 'static check in a different way (which "just" requires good API design & docs).

(If anyone is wondering what it takes to have an Any that soundly handles lifetimes, I sketched the kind of necessary design recently: https://github.com/sagebind/castaway/pull/6#issuecomment-1150952050 - if you're doing MyAny<'a> and it doesn't look at least half as complicated as that sketch, it's probably wrong and can be misused to transmute lifetimes away)