> For many years, the standard library has had an `Infallible` type to work around the unstable nature of the never type. It served the same semantic purpose as the never type, but did not have any special compiler support. Therefore, code using it would be technically correct but suboptimal (such as having an extra layer of tags in an enumeration or emitting dead code), because the optimizer would not always be able to remove references to `Infallible`.
This is incorrect. The compiler has always treated `Infallible` as uninhabited, and used that fact for optimizations. The downside of its lack of compiler support is losing out on the coercions. (The article is excellent otherwise)
show comments
cipherjim
My favourite never type ability is when you need to conform to a trait that returns Result but your specific implementation can never produce an error.
Return Result<T, !> and the compiler knows that callers never have to check the error case because by definition it can’t be constructed.
show comments
xg15
> After this change (and on the 2024 edition), the compiler assumes that T should be !, which doesn't implement Default, and therefore causes a compilation error.
If ! can coerce to every type, why not treat it as if it implemented every trait too?
show comments
LatticeAnimal
Is it obvious to rust developers that "!" would be the never type? I frequently use "never" in typescript. I could imagine using the never type frequently in rust too. I feel like a longer more human-understandable name would've been a good decision here. (feels like more rust jargon that makes the language harder to learn)
show comments
salsa_catsup
Is this so central, that it justifies the use of a single ascii char? Instead of, say, `Never`?
weinzierl
Relevant talk by Waffle at RustWeek earlier this year:
The lesson here is that implicit conversions are bad. The never type itself having implicit conversions to other types is bad enough (even though such coercions are logically valid: “ex falso quodlibet” they should be explicit), but having a fallback type when type inference doesn’t have enough information to produce a type is even worse. Rust is famous for not even having implicit numeric coercions (say from i8 to i32) but it seems like a shortsighted decision to allow implicit coercions here.
show comments
munchler
As a fan of the Curry-Howard correspondence, I approve of this decision.
show comments
epolanski
The never type seems very useful in various languages to either signal that a branch can never happen (the example of string -> bytestring never erroring) or to mark that a function will never return a value (and thus control) to the caller.
A simple TypeScript example:
const forever = (): never => {
while (true) {
// whatever
}
}
HNBeLike
Sounds serious. Armageddon serious.
Nobody should get ahold of this technology.
Shut down the schools!
Get rid of all small business (to mitigate the risk).
> For many years, the standard library has had an `Infallible` type to work around the unstable nature of the never type. It served the same semantic purpose as the never type, but did not have any special compiler support. Therefore, code using it would be technically correct but suboptimal (such as having an extra layer of tags in an enumeration or emitting dead code), because the optimizer would not always be able to remove references to `Infallible`.
This is incorrect. The compiler has always treated `Infallible` as uninhabited, and used that fact for optimizations. The downside of its lack of compiler support is losing out on the coercions. (The article is excellent otherwise)
My favourite never type ability is when you need to conform to a trait that returns Result but your specific implementation can never produce an error.
Return Result<T, !> and the compiler knows that callers never have to check the error case because by definition it can’t be constructed.
> After this change (and on the 2024 edition), the compiler assumes that T should be !, which doesn't implement Default, and therefore causes a compilation error.
If ! can coerce to every type, why not treat it as if it implemented every trait too?
Is it obvious to rust developers that "!" would be the never type? I frequently use "never" in typescript. I could imagine using the never type frequently in rust too. I feel like a longer more human-understandable name would've been a good decision here. (feels like more rust jargon that makes the language harder to learn)
Is this so central, that it justifies the use of a single ascii char? Instead of, say, `Never`?
Relevant talk by Waffle at RustWeek earlier this year:
"When is never?"
https://youtube.com/watch?v=3jM4cnEVrLc
The lesson here is that implicit conversions are bad. The never type itself having implicit conversions to other types is bad enough (even though such coercions are logically valid: “ex falso quodlibet” they should be explicit), but having a fallback type when type inference doesn’t have enough information to produce a type is even worse. Rust is famous for not even having implicit numeric coercions (say from i8 to i32) but it seems like a shortsighted decision to allow implicit coercions here.
As a fan of the Curry-Howard correspondence, I approve of this decision.
The never type seems very useful in various languages to either signal that a branch can never happen (the example of string -> bytestring never erroring) or to mark that a function will never return a value (and thus control) to the caller.
A simple TypeScript example:
const forever = (): never => { while (true) { // whatever } }
Sounds serious. Armageddon serious.
Nobody should get ahold of this technology.
Shut down the schools!
Get rid of all small business (to mitigate the risk).
15 days to prevent Never from destabilizing!
We’re all in this together.