The impls of `LifetimeFree` on `std` are technically unsound (but likely fine in practice)

[Kixunil]

Technically, it's possible for std to change any type to have an additional parameter with default being a type with lifetime parameter set to 'static. This is technically possible with any type, though doing it for arrays and such would require new syntax ([T; N]<X>?).

However, practically, this is very unlikely to happen. Still I'm calling it out in case you want to do something about it. I think that collections are closest to this happening because of the default allocator. If the global allocator ever becomes Whatever<'static> this crate will become unsound. Primitive types are probably the least likely.

Maybe it'd be best to try getting this into core. I've seen some discussion about allowing more casts, so maybe it'd be appealing especially if coupled with a derive macro that can check the type signature and implement the trait. (Should be really simple: if a type contains lifetime parameters emit an error pointing at them, if it doesn't take all type parameters T1...Tn and emit unsafe impl<T1: LifetimFree, T2: LifetimFree, T3: LifetimFree, ..., Tn: LifetimFree> LifetimFree for Foo {}).

[sagebind]

Thank you for raising this issue. Indeed you are right that this is a potential issue in the future. Historically, Castaway has always been a little... dangerous in the assumptions it makes, usually relying on "what does rustc do today" beyond just what the language actually promises. This is not an ideal state of affairs, but it has been the only way of achieving this kind of operation up to this point.

Castaway started as just a little experiment one day. I got nerd-sniped by someone claiming that it couldn't be done, and I wondered, "Hmm, can it be done?" I honestly never expected Castaway to gain so much interest and usage, and the fact that it has, to me indicates a hole in core that would be nice to be filled in a more proper way.

Arguably, the entire operation that Castaway offers could itself be provided by a core function const fn try_cast<T, U>(T) -> Result<U, T> wrapping an intrinsic using knowledge that probably should be available in rustc. However, a more minimal ask I might have is for core to provide two safe functions:

• const fn type_eq_ignoring_lifetimes<T: ?Sized, U: ?Sized>() -> bool
  • This should be doable today using core::intrinsics::type_id if the 'static bound can be dropped from it. I believe there's already a lot of discussion on this over the years.
• const fn type_contains_lifetimes<T: ?Sized>() -> bool
  • A trait such as LifetimeFree is perhaps a better design, perhaps not. Castaway only uses a trait in the way it does for technical limitations and no other.

The existence of functions like these would allow Castaway to be fully sound in the future as defined by guarantees of those functions. That said, beggars can't be choosers, and Castaway will gladly accept any bone that is tossed our way by the core language, however small.

Of course, it can be argued that specialization is the thing that addresses this, but at least for now I have no hope of Rust ever having a stable specialization feature.

[Kixunil]

I guess intrinsics would work too but I personally find the trait more readable. It also works as an API promise that some stuff won't break. E.g. changing Foo(&'static str) to Foo<T = &'static str>(T) is currently not a breaking change but it would be once there is any such mechanism.