RFC 1892 suggests to deprecate
std::mem::uninitialized. The main motivation is to solve problem of unsoundness around creating values of uninhabited types (e.g.
Void). In my opinion it looks like plugging holes without solving an underlying issue: currently we don’t have a way to distinguish inhabited and non-inhabited types on type-level. Thus constraints which will make code safer can not be expressed properly. The RFC lists “the old
Inhabited trait proposal” trait proposal as an alternative, but unfortunately I couldn’t find it.
IIUC the main issue with introducing
Inhabited trait is that to make it work, it will have to be an automatic trait bound, so e.g. for
Result variants we’ll have to explicitly use
?Inhabited bound on its variants. But this change can’t be done in a straightforward fashion, as it can break a lot of code. The most common uses of uninhabited types include:
- FFI types (arguably a dirty hack, should be replaced with extern types)
- Marker types (think e.g.
byteordercrate), these types can benefit from explicit
Voidlike types (which will be superseded by never type), arguably the only sensible use for them is in enum variants, to denote “impossible” cases.
Inhabited trait can be introduced in a backwards compatible way? As I see it, solution is make
Inhabitted auto-bound violation to issue warnings instead of compile-time error in Rust 2018 edition, and make it a hard error in the next edition. While this approach raises difficult questions regarding how it can be implemented, I think that in a long run we better have a proper
Inhabited trait than plug holes here and there.