1 matches bool, 2 matches long

Diggory diggsey at googlemail.com
Fri Apr 26 13:59:56 PDT 2013


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.


More information about the Digitalmars-d mailing list