But I guess I shouldn't be surprised when using unstable features.
Is it really so bad? At least it catches the problem when I attempt to use the method.
The #![feature(specialization)] gives an explicit warning, which #![feature(negative_impls, with_negative_coherence)] does not.
This is my current use case: Playground.
The GAT AlignedRef<'a> allows me to return a reference to unaligned types such as &str but to return a clone of structures that require alignment using the Owned smart-pointer (as the stored data types are coming from LMDB where alignment isn't guaranteed).
I (supposedly) need the negative impl's and negative coherence to later implement Storable on tuples of StorableConstBytesLen types automatically, while being able to implement Storable on other tuples (e.g. tuples of smart pointers where the target is Storable) as well.
A workaround for me is to always declare a newtype for anything that I want to store and then implement Storable on that particular newtype and avoid the generic implementations altogether. I'm not sure what's worse: the extra effort to always implement Storable manually or using a half-baked feature.