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.

Reply via email to