flesh out void types

pull/10/head
Alexis Beingessner 9 years ago committed by Manish Goregaokar
parent 42ed931268
commit 7415230ad1

@ -81,9 +81,33 @@ consider passing in `0` as Undefined Behaviour.
Rust also enables types to be declared that *cannot even be instantiated*. These
types can only be talked about at the type level, and never at the value level.
Empty types can be declared by specifying an enum with no variants:
```rust
enum Foo { } // No variants = EMPTY
enum Void {} // No variants = EMPTY
```
TODO: WHY?!
Empty types are even more marginal than ZSTs. The primary motivating example for
Void types is type-level unreachability. For instance, suppose an API needs to
return a Result in general, but a specific case actually is infallible. It's
actually possible to communicate this at the type level by returning a
`Result<T, Void>`. Consumers of the API can confidently unwrap such a Result
knowing that it's *statically impossible* for this value to be an `Err`, as
this would require providing a value of type Void.
In principle, Rust can do some interesting analysees and optimizations based
on this fact. For instance, `Result<T, Void>` could be represented as just `T`,
because the Err case doesn't actually exist. Also in principle the following
could compile:
```rust,ignore
enum Void {}
let res: Result<u32, Void> = Ok(0);
// Err doesn't exist anymore, so Ok is actually irrefutable.
let Ok(num) = res;
```
But neither of these tricks work today, so all Void types get you today is
the ability to be confident that certain situations are statically impossible.

Loading…
Cancel
Save