Skip to content

Commit 99043dd

Browse files
committed
mention void pointers
1 parent 5f6e0ab commit 99043dd

File tree

1 file changed

+8
-3
lines changed

1 file changed

+8
-3
lines changed

src/doc/tarpl/exotic-sizes.md

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -95,10 +95,9 @@ actually possible to communicate this at the type level by returning a
9595
knowing that it's *statically impossible* for this value to be an `Err`, as
9696
this would require providing a value of type Void.
9797

98-
In principle, Rust can do some interesting analysees and optimizations based
98+
In principle, Rust can do some interesting analyses and optimizations based
9999
on this fact. For instance, `Result<T, Void>` could be represented as just `T`,
100-
because the Err case doesn't actually exist. Also in principle the following
101-
could compile:
100+
because the Err case doesn't actually exist. The following *could* also compile:
102101

103102
```rust,ignore
104103
enum Void {}
@@ -111,3 +110,9 @@ let Ok(num) = res;
111110

112111
But neither of these tricks work today, so all Void types get you today is
113112
the ability to be confident that certain situations are statically impossible.
113+
114+
One final subtle detail about empty types is that raw pointers to them are
115+
actually valid to construct, but dereferencing them is Undefined Behaviour
116+
because that doesn't actually make sense. That is, you could model C's `void *`
117+
type with `*const Void`, but this doesn't necessarily gain anything over using
118+
e.g. `*const ()`, which *is* safe to randomly dereference.

0 commit comments

Comments
 (0)