Represent equivalent enums the same as bool, make bool an enum

[glaebhoerl]

CLICKME

[reem]

If we're doing this, which I am in favor of, we should probably changed the type to Bool and the variants to True and False, signaling that it is not so special.

Precedence: Haskell

[blaenk]

Yeah, making them True and False would be more consistent.

[glaebhoerl]

But it would be inconsistent with the C family of languages whose practitioners we are trying to look familiar to. And in any case the two things, naming and implementation, are almost completely orthogonal. I would rather have the capitalization debate separately.

[nrc]

I don't think we should force this - we currently reserve the right to change all our default data representations and that is nice flexibility to have. You can request this using the c-repr annotation, and of course you could put that on the bool enum, which fulfils your use case, I think.

[glaebhoerl]

I tried to address this under "Arguments against". Do you have a counter-counterargument? I know we do currently reserve this right, but I don't see how the flexibility is at all useful in this case.

[nrc]

There are certainly things we might want to do - e..g, represent an array of enums as a bit field or something. I think just because we can't think of something now doesn't mean we won't think of something in the future. In particular in this case, because even if we take the rest of this RFC I see essentially no downside in having to annotate bool-like enums with C-repr

[glaebhoerl]

represent an array of enums as a bit field or something

This specifically would break interior references.

But in general, as noted by another comment, any representation change you'd want to do for bools, you would also want to do for the equivalent types. They only differ, after all, in naming. If you like, this is a specific case of the more general property that representations of types which differ only in their names and the names of their fields/variants should always be the same. (Because there is absolutely no reason the compiler would ever want to choose different representations based on just names.)

[bill-myers]

This syntax might better achieve the desired goals:

enum Answer : bool
{
  Yes = true,
  No = false
}

[ftxqxd]

@bill-myers The current way of specifying what type to represent an enum with is using the #[repr] attribute:

#[repr(u8)]
enum Foo {
    Bar = 1,
    Baz = 2,
}

Simply allowing #[repr(bool)] would be fine.

[liigo]

bool true false are core language type/values. If defines them in
standard library, people can't use them without core/std crate.

[Ericson2314]

Again, something I thought of proposing once but never got around to. Thank you, @glaebhoerl!

@liigo they would go in Core, which is really minimal and should be usable in all projects.

I agree the representation shouldn't be forced, but I think that strengthens the case for this. Any optimizations that could be done with bools (bitvectors, bitfields, control-flow vs data-flow tricks, conditional mov, etc) ought to be available to all isomorphic types.

Most of those optimizations should be handled by LLVM anyways, so I'd hope this might actually not be too complex.

I'd like to also make all if-relating things macros around pattern matching so we don't need the lang_item, but I recognize that might scare some people. :)

[Ericson2314]

Also +1 for upper case identifiers. I'd like to do upper case names for the integer types too, C/C++/Java be damned, but if this becomes library defined then upper casing it should be given special priority.

[aturon]

@glaebhoerl At a first glance, it seems like this change could be done post-1.0, backwards-compatibly, but I could easily be wrong. Have you given that any thought?

[glaebhoerl]

I assumed it couldn't be, because keywords are "always in scope" whereas prelude entities aren't necessarily. In particular #[no_implicit_prelude] modules would break.

[aturon]

I assumed it couldn't be, because keywords are "always in scope" whereas prelude entities aren't necessarily. In particular #[no_implicit_prelude] modules would break.

True, although I suspect this could be worked around if need be. But it also seems like the aspect of the proposal involving keywords is separable from the part dealing with the enum representation, and I think the latter could be introduced without any troubles.

(FWIW, I'm in principle in favor of most of the proposal, but we only have so much time before 1.0, so I'm trying to see what the tradeoffs are if we postpone consideration.)

[glaebhoerl]

Concerns about representation came up last time this was discussed (can't remember where that was), which is why I took these together.

[huonw]

Another argument for is improved documentation, since things can be attached to bool directly & it would get its own doc page in the normal way.

[aturon]

We discussed this RFC at the triage meeting today, and decided:

1. That collectively, we do not see enough advantage to removing the true and false keywords to warrant the pain.
2. That we are interested in making bool an enum in the long run, but without the keyword removal this can be done later, backwards-compatibly.

Therefore, we are postponing (the enum part of) this RFC. I've created a tracking issue for it.