Closed
Description
< bstrie> pcwalton: you wouldn't need to count true and false if they were done
as enums, is there a reason they aren't?
<@pcwalton> bstrie: because enums do not have a defined memory layout but
booleans do
<@pcwalton> anyway, I would probably be in favor of getting rid of "true" and
"false" and doing what Go does
<@pcwalton> since it's somewhat inconsistent that "bool" is not a keyword in
Rust but "true" and "false" are
<@nmatsakis> ...regarding bool, remember we have check exhaustiveness.
<@nmatsakis> an enum would work better
<@pcwalton> nmatsakis: ah, yes. well, enums don't work because bools have size
in rust and we don't specify enum layout
<@pcwalton> at least, I'm proposing that we don't
<@pcwalton> in order to leave room for data layout optimizations (e.g.
Option<~T> becoming a nullable pointer, Result<(),~T> becoming a
nullable pointer, etc)
<@nmatsakis> pcwalton: I think we should permit the layout of enums to be
specified with annotations.
<@nmatsakis> so bool could be labeled.
<@nmatsakis> we're defining it, anyhow.
<@pcwalton> hmm
< strcat> pcwalton: bool could just rely on the implementation details, since
it's part of the implementation
<@pcwalton> that might work yeah
< strcat> just make the discriminant only as big as needed and it'll be 1 byte
< strcat> pcwalton: or you could say the layout is implementation defined if it
contains pointers/arrays/strings
<@pcwalton> hmm, yes, that's possible
Metadata
Metadata
Assignees
Labels
No labels