Skip to content

RFC: turn true and false into enums #5266

Closed
@bstrie

Description

@bstrie
< 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions