Make `bool` an `enum`

[aturon]

Currently, bool is not an enum, but there's no strong reason for that state of affairs. Making it an enum would increase overall consistency in the language.

This is a backwards-compatible change (depending on the specifics) and has been postponed till after 1.0.

See #330.

[Centril]

Whatever happened to this? =P

(is it still backwards compatible?)

[SimonSapin]

We document:

https://doc.rust-lang.org/1.34.0/std/primitive.bool.html

If you cast a bool into an integer, true will be 1 and false will be 0.

Casting here likely refers to the as operator.

However as far as I can tell we currently make no promise about the memory representation of bool (other than size_of being 1 byte). We may want to keep it that way, for #954.

If bool is a primitive rather an enum, we can (more easily) special-case its casting behavior in the language.

[oberien]

Wouldn't the casting behaviour and guaranteed size_of still be possible with repr(u8)? (even though that might be a problem with #954)

#[repr(u8)]
enum bool {
    false = 0,
    true = 1,
}

[gorilskij]

The problem with representing bool as an enum is that it's either backwards-compatible (bool, true, false) or it conforms to the CamelCase naming convention for enums defined in RFC #430 (Bool, True, False), not both.

[RustyYato]

@gorilskij I don't see how this is a big issue. Obviously we have to preserve true and false and be inconsistent with CamelCase
How is this that bad though?

[gorilskij]

@KrishnaSannasi I would tend to agree, both for compatibility and because bool is a basic enough type to warrant a lower case name. It's not bad, just unpleasantly inconsistent, especially in a language as relatively polished as Rust. It's not nice to have a builtin type that, were you to write it yourself, would raise a compiler warning.

There is another, more serious point. As proven by the fact that false is 0 and true is 1, bool is more than just a simple 2-variant enum, it has a u1 kind of numeric feeling to it, logical operations have a numerical operation feeling to them as well as evidenced by some of the notation (&& ~= *, || ~= +, ...) not to mention the fact that all those operations as well as the if/else construct depend on the bool type, it would be possible to do logic without all of that but with how fundamentally useful it is, I think it (bool and friends) deserves it's special status in Rust as in the vast majority of other languages.

As an example to illustrate what I mean, Haskell implements Bool as a true 2-variant type and defines the infix operators (&&, ||, ...) in the standard way to go along with it (note that logical not is called not, not ! to maintain consistency because it's a prefix operator, though Haskell does still bend the rules for prefix - but that's beside the point). This, I believe, is nice and idealistic but not suited to a more practical language like Rust.

TL;DR I think making bool an enum changes nothing from the implementation perspective and goes half-way in a direction I'm not sure we should be going from the purity perspective.

[RustyYato]

@gorilskij

There is another, more serious point. As proven by the fact that false is 0 and true is 1, bool is more than just a simple 2-variant enum, it has a u1 kind of numeric feeling to it

I would argue that a u1 is just a 2-variant enum, and that any numeric properties it has are just semantics for us, but don't really need to be encoded into it's representation.

Also a bool can be represented as @oberien showed earlier,

#[repr(u8)]
enum bool {
    false = 0,
    true = 1
}

and then special casing && and ||. The other operators (like !) can be implemented normally.

Note that there is movement to make && and || overloadable like all of the other operators. If that lands, then we can implement && and || normally for bool as well.

One more advantage to this is that it reduces the number of keywords in Rust, because bool, true and false no longer have to be keywords.

edit: bool is not a keyword, my bad