1 matches bool, 2 matches long

[Walter Bright]

On 4/26/2013 3:28 PM, Jonathan M Davis wrote:
> Sure, it may be useful sometimes to have code that treats true as 1 and false
> as 0 for math, but I'd argue for casting being required for it, and in a large
> number of cases, casting would be required already due to the fact that it
> would be a narrowing conversion. But it seems very wrong to me that foo(1)
> would call a bool overload or that "foo" ~ true would compile.

It's not any different from how char is treated (char is also treated as an 
integer type).


> There have been
> a number of posts over time discussing bugs caused by that behavior being
> legal. I don't think that it's a huge problem, but I do think that it's a
> problem.

In general, D treats bool, char, wchar, and dchar as integer types. D also 
follows the C practice of unadorned integer literals being typed as ints, and 
the C practice of default integral promotions.

If you're not aware of this, yes, you can get surprised when working with 
overloads across those types.

The solution in the antecedent's particular case is to add an overload foo(int), 
which will neatly prevent any unadorned integer literals from being implicitly 
cast to char or bool or whatever. It's also a good practice in that 
unnecessarily promoting ints to longs is a bit of an efficiency issue.

[Generally, I'd raise a red flag on any code that only provided foo(bool) and 
foo(long) overloads.]


> However, we are clearly coming from very different points of view
> here.

Thanks for understanding my point that this is not a right or wrong issue, but a 
matter of perspective.