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 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. 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 ```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