Whatever the choices are of whether bool is a 1-bit integer or a
a logical true/false value, this should not happen:
enum e = 1;
void main()
{
foo(e); // bool
}
static e = 1;
void main()
{
foo(e); // long
}
The reason being that according to the language spec, the
constant "1" should be an int. Whether or not it implicitly
converts to a bool, this means that "enum e" should have a type
of int as well. The actual value shouldn't be taken into account
when determining which overload to call, only the type should
matter, and an unknown int value should implicitly convert to a
long not a bool. Automatic conversion of "1" to bool should only
be able to happen at the point where the literal is used if at
all:
enum bool e = 1;
Ideally such an implicit conversion would only apply if it was
the only possible valid implicit conversion, so this:
foo(1)
Should at least warn of the ambiguity.
Compile-time conversions based on value rather than type are by
definition going to break the type system. Therefore the only way
to get "1" to normally be an "int" but automatically convert to a
"bool" without being inconsistent is to effectively introduce a
new type for the literal "1" which has the desired conversions
(the same way that zero has a special type in C/C++ which can
convert to both an integer or a pointer).
The important thing is that this special type for "1" should
never transfer to other things: the type of the literal should be
fixed to a normal type at the point where it is used to prevent
surprising the user (this is what C/C++ does).
At the moment "enum e = 1;" transfers the special properties of
"1" to "e" and I think that's more than a little surprising.
