Tracking issue for non_static_type_id #41875

eddyb · 2017-05-10T11:14:40Z

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 · 2017-05-10T11:21:26Z

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)

ghost · 2017-05-10T15:39:54Z

I'd like to participate on this :)

eddyb · 2017-05-10T19:16:05Z

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

fcofdez · 2017-05-16T23:39:38Z

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

ghost · 2017-05-17T01:12:00Z

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

kennytm · 2017-05-28T14:08:32Z

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 · 2017-05-28T14:29:46Z

@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 · 2017-05-29T08:38:48Z

@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 · 2017-05-29T10:23:10Z

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 · 2017-06-16T06:10:22Z

@z1mvader Are you still working on this?

ghost · 2017-06-16T15:30:22Z

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

kennytm · 2017-06-16T15:46:06Z

@z1mvader o_O No I did not write any code on this, I was just making a comment in this thread 😅...

Aceeri · 2017-06-28T09:13:26Z

I'll be working on this tomorrow, just so anyone who is watching this issue knows.

Aceeri · 2017-07-02T13:40:20Z

Turns out this doesn't exactly help with my problem so I'm probably not going to be finishing my PR for this. Rustc also doesn't want to build properly on my machine, so I'd rather not waste too much time trying to fix it.

dtolnay · 2017-07-24T00:18:15Z

Here is a quick workaround for anyone waiting on this to be implemented.

#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Hash)] pub struct TypeId { id: usize, } impl TypeId { pub fn of<T: ?Sized>() -> Self { TypeId { id: TypeId::of::<T> as usize, } } }

Edit: Better:

use core::any::TypeId;
use core::marker::PhantomData;
use core::mem;

pub fn non_static_type_id<T: ?Sized>() -> TypeId {
    trait NonStaticAny {
        fn get_type_id(&self) -> TypeId where Self: 'static;
    }

    impl<T: ?Sized> NonStaticAny for PhantomData<T> {
        fn get_type_id(&self) -> TypeId where Self: 'static {
            TypeId::of::<T>()
        }
    }

    let phantom_data = PhantomData::<T>;
    NonStaticAny::get_type_id(unsafe {
        mem::transmute::<&dyn NonStaticAny, &(dyn NonStaticAny + 'static)>(&phantom_data)
    })
}

eddyb · 2017-07-24T03:52:04Z

@dtolnay How... is that guaranteed to work, at all? Not to mention that having TypeId work, instead of just the intrinsic, suggests potential misuse. Do you want it for something Any-like? In that case, you're likely building something unsound.

dtolnay · 2017-07-24T04:09:59Z

It worked great when I tried it 🤷‍♂️. Here is the intrinsic version.

pub fn type_id<T: ?Sized>() -> u64 {
    type_id::<T> as usize as u64
}

kennytm · 2017-07-24T04:15:07Z

@dtolnay I don't see how that's gonna work besides causing infinite recursion 😄

eddyb · 2017-07-24T04:17:44Z

Note that it doesn't call, it casts a function pointer. But I expect mergefunc (-C opt-level=3 enables that optimization, if we still have it) might want to collapse all of those instances into one, and this clearly can't work cross-crate.

dtolnay · 2017-07-24T04:30:59Z

Seems to work with -C opt-level=3, and I don't need it cross-crate. 🎊

eddyb · 2017-07-24T04:34:12Z

@dtolnay Still, there is nothing guaranteeing this won't be optimized away - if mergefunc is enabled right now, I'd even consider its failure to collapse those instances as a bug.
I consider it a bit irresponsible to suggest it to people who might write unsafe code off of it.

Avi-D-coder · 2020-05-02T21:31:00Z

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 · 2020-05-02T21:37:03Z

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 · 2020-05-02T22:04:09Z

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 · 2020-05-02T22:16:36Z

@rfcbot cancel

rfcbot · 2020-05-02T22:16:36Z

@joshtriplett proposal cancelled.

joshtriplett · 2020-05-02T22:21:09Z

@rfcbot close

rfcbot · 2020-05-02T22:21:10Z

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

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 · 2020-05-11T14:42:08Z

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

nikomatsakis · 2020-05-11T14:42:39Z

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 · 2020-05-21T14:47:55Z

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 · 2020-05-21T21:31:02Z

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.

…komatsakis Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated rust-lang#41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature, which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage, but I’ve included some more below. As a simple example, you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::<u32>(), TypeId::of::<i32>(), ]; assert_eq!(TypeId::of::<u32>(), TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::<Self>(); } impl<T: 'static> Any for T { } assert_eq!(TypeId::of::<usize>(), usize::TYPE_ID); ``` `TypeId::of` is generic, which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property, which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of`, other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions, so violating it using type ids isn’t new. As an example of how impls can behave differently, you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self`, rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::<Self>`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::<usize>(); match TypeId::of::<Self>() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }), // For other types, dispatch to the generic `Self::default`. _ => Self::default, } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl<T: fmt::Debug + 'static> Specialized for T { fn default(x: &Self) { println!("default: {:?}", x); } fn usize(x: &usize) { println!("usize: {:?}", x); } } // Will print "usize: 42" Specialized::call(&42usize); // Will print "default: ()" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions, it's never valid to cast a type id to its underlying value.

dtolnay · 2022-07-24T20:23:06Z

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 · 2022-07-24T20:58:53Z

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: sagebind/castaway#6 (comment) - 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)

eddyb added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 10, 2017

eddyb added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels May 10, 2017

eddyb mentioned this issue May 10, 2017

Remove static bound from type_id rust-lang/rfcs#1849

Merged

Mark-Simulacrum mentioned this issue May 18, 2017

TypeId only allows sized types that have a 'static bound #20168

Closed

Aceeri mentioned this issue May 29, 2017

TrackedStorage (flagged component storage) amethyst/specs#89

Closed

Mark-Simulacrum mentioned this issue Jul 10, 2017

Rework Rustbuild to an eagerly compiling approach #43059

Merged

Mark-Simulacrum added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 27, 2017

rfcbot removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. labels May 2, 2020

joshtriplett added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed T-lang Relevant to the language team, which will review and decide on the PR/issue. labels May 2, 2020

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. labels May 2, 2020

rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels May 11, 2020

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels May 21, 2020

nikomatsakis closed this as completed May 21, 2020

KodrAus mentioned this issue May 23, 2020

Stabilize const_type_id feature #72488

Merged

jlindsey mentioned this issue Jun 4, 2020

Allow to get the original error message inside a catch registered via catchers!() rwf2/Rocket#1234

Closed

cfrantz mentioned this issue Feb 8, 2022

Support emitting comments, blocks and alternate integer encodings in serialized output dtolnay/serde-yaml#234

Closed

mstone mentioned this issue Jan 26, 2023

Tracking Issue for Provider API #96024

Open

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for non_static_type_id #41875

Tracking issue for non_static_type_id #41875

eddyb commented May 10, 2017

eddyb commented May 10, 2017

ghost commented May 10, 2017

eddyb commented May 10, 2017

fcofdez commented May 16, 2017

ghost commented May 17, 2017

kennytm commented May 28, 2017 •

edited

Loading

eddyb commented May 28, 2017

kennytm commented May 29, 2017

eddyb commented May 29, 2017

Aceeri commented Jun 16, 2017

ghost commented Jun 16, 2017

kennytm commented Jun 16, 2017

Aceeri commented Jun 28, 2017

Aceeri commented Jul 2, 2017

dtolnay commented Jul 24, 2017 •

edited

Loading

eddyb commented Jul 24, 2017

dtolnay commented Jul 24, 2017

kennytm commented Jul 24, 2017

eddyb commented Jul 24, 2017

dtolnay commented Jul 24, 2017

eddyb commented Jul 24, 2017

Avi-D-coder commented May 2, 2020

bluss commented May 2, 2020 •

edited

Loading

Avi-D-coder commented May 2, 2020 •

edited

Loading

joshtriplett commented May 2, 2020

rfcbot commented May 2, 2020

joshtriplett commented May 2, 2020

rfcbot commented May 2, 2020 •

edited by nikomatsakis

Loading

rfcbot commented May 11, 2020

nikomatsakis commented May 11, 2020

rfcbot commented May 21, 2020

nikomatsakis commented May 21, 2020

dtolnay commented Jul 24, 2022

eddyb commented Jul 24, 2022 •

edited

Loading

Tracking issue for non_static_type_id #41875

Tracking issue for non_static_type_id #41875

Comments

eddyb commented May 10, 2017

eddyb commented May 10, 2017

ghost commented May 10, 2017

eddyb commented May 10, 2017

fcofdez commented May 16, 2017

ghost commented May 17, 2017

kennytm commented May 28, 2017 • edited Loading

eddyb commented May 28, 2017

kennytm commented May 29, 2017

eddyb commented May 29, 2017

Aceeri commented Jun 16, 2017

ghost commented Jun 16, 2017

kennytm commented Jun 16, 2017

Aceeri commented Jun 28, 2017

Aceeri commented Jul 2, 2017

dtolnay commented Jul 24, 2017 • edited Loading

eddyb commented Jul 24, 2017

dtolnay commented Jul 24, 2017

kennytm commented Jul 24, 2017

eddyb commented Jul 24, 2017

dtolnay commented Jul 24, 2017

eddyb commented Jul 24, 2017

Avi-D-coder commented May 2, 2020

bluss commented May 2, 2020 • edited Loading

Avi-D-coder commented May 2, 2020 • edited Loading

joshtriplett commented May 2, 2020

rfcbot commented May 2, 2020

joshtriplett commented May 2, 2020

rfcbot commented May 2, 2020 • edited by nikomatsakis Loading

rfcbot commented May 11, 2020

nikomatsakis commented May 11, 2020

rfcbot commented May 21, 2020

nikomatsakis commented May 21, 2020

dtolnay commented Jul 24, 2022

eddyb commented Jul 24, 2022 • edited Loading

kennytm commented May 28, 2017 •

edited

Loading

dtolnay commented Jul 24, 2017 •

edited

Loading

bluss commented May 2, 2020 •

edited

Loading

Avi-D-coder commented May 2, 2020 •

edited

Loading

rfcbot commented May 2, 2020 •

edited by nikomatsakis

Loading

eddyb commented Jul 24, 2022 •

edited

Loading