The section Other reprs > repr(u*), repr(i*) says:
Adding an explicit repr(u*), repr(i*), or repr(C) to an enum with fields suppresses the null-pointer optimization, like:
[Example code omitted]
This optimization still applies to fieldless enums with an explicit repr(u*), repr(i*), or repr(C).
What in the world can the null-pointer optimization do without a field? (In fact, a field having one of several types, such as reference, Box, NonNull, NonZero, or a transparent wrapper around another such type, but most importantly, a field, the very thing that fieldless enums do not have.
I am most puzzled as to what is meant here.
Apparently @joshtriplett added this in #315? Perhaps he can figure out what he meant?
If it was just that this doesn't cause rustc to forget about niches in the fieldless enum, that's covered higher up, in the sentence:
Adding a repr(u*)/repr(i*) causes it to be treated exactly like the specified integer type for layout purposes (except that the compiler will still exploit its knowledge of "invalid" values at this type to optimize enum layout, such as when this enum is wrapped in Option).
Though I'm not sure those optimizations are guaranteed to start with; they aren't mentioned in https://doc.rust-lang.org/std/option/index.html#representation …
The section Other reprs > repr(u*), repr(i*) says:
What in the world can the null-pointer optimization do without a field? (In fact, a field having one of several types, such as reference,
Box,NonNull,NonZero, or a transparent wrapper around another such type, but most importantly, a field, the very thing that fieldless enums do not have.I am most puzzled as to what is meant here.
Apparently @joshtriplett added this in #315? Perhaps he can figure out what he meant?
If it was just that this doesn't cause rustc to forget about niches in the fieldless enum, that's covered higher up, in the sentence:
Though I'm not sure those optimizations are guaranteed to start with; they aren't mentioned in https://doc.rust-lang.org/std/option/index.html#representation …