Go over all libstd traits and see which of them !/TyNever should implement

E.g. ! should implement Default.

@rustbot

@rustbot label F-never_type

The conditions under which it is reasonable for ! to implement a trait are:

All functions accept an argument of type Self
The trait does not have associated types¹

I went through all of the traits in the standard library, here is my analysis:

Most traits which make sense to implement for ! are already implemented
Because ! inherently relates to dead code it's very hard to come up with actual use-cases
There are a lot of traits which could be implemented for !, but why would you need it?

IMO it's better to go on a case-by-case basis. I.e. if there is a use case for a certain trait to be implemented, implement it specifically, rather than trying to implement all that could be implemented.

Here is a table with all traits in std:

trait	decision	comment
`std::alloc::GlobalAlloc`	no	while it fulfills the conditions, to use this trait you need a `static` with a value of `Self`, which is not possible for `!`
`std::alloc::Allocator`	yes	I'm not fully sure, but it feels like there should be a use case?
`std::any::Any`	yes²	implemented for all types
`std::ascii::AsciiExt`	no	deprecated, assoc type
`std::borrow::Borrow`	yes
`std::borrow::BorrowMut`	yes
`std::borrow::ToOwned`	no	assoc type
`std::clone::Clone`	yes²
`std::clone::CloneToUninit`	yes²
`std::clone::UseCloned`	yes?	seems mostly irrelevant
`std::cmp::Eq`	yes²
`std::cmp::Ord`	yes²
`std::cmp::PartialEq`	yes²
`std::cmp::PartialOrd`	yes²
`std::convert::AsMut`	yes
`std::convert::AsRef`	yes
`std::convert::From`	no	it doesn't make sense to convert `T -> !`. `for<T> From<!> for T` could make sense, but it overlaps with `for<T> From<T> for T` and thus isn't happening
`std::convert::Into`	no	see `From`
`std::convert::TryFrom`	no	see `From`
`std::convert::TryInto`	no	see `From`
`std::convert::FloatToInt`	no	`!` is not a float
`std::default::Default`	no	`default` doesn't take an argument of type `Self`
`std::error::Error`	yes²
`std::ffi::VaArgSafe`	no	you can't pass `!` in varargs...
`std::fmt::Binary`	yes?	not as useful as `Debug`/`Display`, but why not
`std::fmt::Debug`	yes²
`std::fmt::Display`	yes²
`std::fmt::LowerExp`	yes?	not as useful as `Debug`/`Display`, but why not
`std::fmt::LowerHex`	yes?	not as useful as `Debug`/`Display`, but why not
`std::fmt::Octal`	yes?	not as useful as `Debug`/`Display`, but why not
`std::fmt::Pointer`	yes?	not as useful as `Debug`/`Display`, but why not
`std::fmt::UpperExp`	yes?	not as useful as `Debug`/`Display`, but why not
`std::fmt::UpperHex`	yes?	not as useful as `Debug`/`Display`, but why not
`std::fmt::Write`	yes?³
`std::future::Future`	no	assoc type
`std::future::IntoFuture`	no	assoc type
`std::future::AsyncDrop`	no	irrelevant
`std::hash::BuildHasher`	no	assoc type
`std::hash::Hash`	yes²
`std::hash::Hasher`	yes?³
`std::io::BufRead`	yes?³
`std::io::IsTerminal`	yes?³
`std::io::Read`	yes?³
`std::io::Seek`	yes?³
`std::io::Write`	yes?³
`std::iter::DoubleEndedIterator`	no	assoc type
`std::iter::ExactSizeIterator`	no	assoc type
`std::iter::Extend`	yes?³
`std::iter::FromIterator`	no	`from_iter` doesn't accept an argument of type `Self`
`std::iter::FusedIterator`	no	assoc type
`std::iter::IntoIterator`	no	assoc type
`std::iter::Iterator`	no	assoc type
`std::iter::Product`	no	`product` doesn't accept an argument of type `Self`
`std::iter::Sum`	no	`sum` doesn't accept an argument of type `Self`
`std::iter::Step`	yes?³
`std::iter::TrustedLen`	no	assoc type
`std::iter::TrustedStep`	no	irrelevant, optimization only
`std::marker::Copy`	yes²
`std::marker::Send`	yes²
`std::marker::Sized`	yes²	automatically implemented
`std::marker::Sync`	yes²
`std::marker::Unpin`	yes²
`std::marker::ConstParamTy_`	no	you can't have a value of `!`, so you can't pass it as a const generic parameter
`std::marker::Destruct`	yes²⁴
`std::marker::DiscriminantKind`	no	assoc type
`std::marker::FnPtr`	no⁵	`FnPtr` seems to only be used as a bound for `fn_addr_eq` and is perma-unstable. there is never a need for the `!` impl
`std::marker::Freeze`	yes²
`std::marker::MetaSized`	yes²	automatically implemented
`std::marker::PointeeSized`	yes²	automatically implemented
`std::marker::StructuralPartialEq`	no	used for pattern matching, you can't have a value of `!` => that'd be useless
`std::marker::Tuple`	no	not a tuple
`std::marker::Unsize`	no	automatically implemented / not relevant
`std::marker::UnsizedConstParamTy`	no	same as `ConstParamTy_`?
`std::marker::Variance`	no	not a variance type
`std::mem::TransmuteFrom`	?	implemented by the compiler, unclear if it matters for `!`
`std::net::ToSocketAddrs`	no	assoc type
`std::num::ZeroablePrimitive`	no	`!` is never valid
`std::ops::*Assign`	yes?³
`std::ops::Not`	yes?²	see #91122 for the reasoning
`std::ops::Neg`	yes?³	similarly to `Not`? There hasn't been a feature request for that yet...
`std::ops::Drop`	no	no need for a destructor / `!: Copy`
`std::ops::RangeBounds`	yes?³
`std::ops::CoerceUnsized`	no	never type doesn't use or need unsize coercions (because there is always never to any)
`std::ops::DispatchFromDyn`	no	doesn't make sense
`std::ops::IntoBounds`	yes?³
`std::ops::OneSidedRange`	yes?³
`std::ops::*` (the rest)	no	assoc types⁶
`std::panic::RefUnwindSafe`	yes²
`std::panic::UnwindSafe`	yes²
`std::pin::PinCoerceUnsized`	no	irrelevant
`std::process::Termination`	yes²
`std::ptr::Pointee`	yes²	automatically implemented for all types
`std::slice::SliceIndex`	no	assoc type
`std::slice::Concat`	no	assoc type
`std::slice::Join`	no	assoc type
`std::std::FromStr`	no	`!` can't be constructed and thus can't be parsed
`std::string::ToString`	yes²
`std::sync::atomic::AtomicPrimitive`	no	not an atomic primitive
`std::task::Wake`	yes?³
`std::task::LocalWake`	yes?³
`std::async_iter::AsyncIterator`	no	assoc type
`std::async_iter::IntoAsyncIterator`	no	assoc type
`std::random::Distribution`	yes?³
`std::random::RandomSource`	yes?³
`std::range::IntoBounds`	yes?³
`std::range::OneSidedRange`	yes?³
`std::range::RangeBounds`	yes?³
`std::range::Step`	yes?³
`std::simd::*`	no	irrelevant

and there are multiple potential choices for it ↩
! already implements this traits ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶
I don't see a usecase, but it's possible ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²²
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=c1b0e0dc1208eb8871b7e22712768fb9 ↩
possible to implement, but useless ↩
technically it's possible to have for<T> !: Add<T, Output = T>, but why would you need this?... ↩

Navigation Menu

Repository navigation

Go over all libstd traits and see which of them !/TyNever should implement #35866

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Go over all libstd traits and see which of them !/TyNever should implement #35866

Description

Activity

Jules-Bertholet commented on Jul 3, 2023

WaffleLapkin commented on Oct 18, 2025

Footnotes

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions