On Thu, 25 Apr 2013 23:01:30 -0700, Walter Bright
<newshou...@digitalmars.com> wrote:
D tries very hard to avoid the notion of a "better" match. It goes with
an exact match, followed by one with implicit conversions. All implicit
conversions are considered equally good. Ambiguity is resolved by
invoking "partial ordering", which was explained elsewhere in this
thread. Partial ordering does not at all consider "better" matches.
I think the issue (and I am firmly in the foo(1) => long camp) is that
bools are considered better integers than actual integer types (or even
floating point types for that matter). I agree that bools can be
implicitly cast to and from integers, as a last resort.
Once you venture down the path of "better" matches, it's all roses at
first, but look at where C++ wound up with it. It didn't intend to
arrive there, it inevitably arrived there.
bool is true or false. It can be interchangeable with 0 or 1. But if
it's overloaded with an integral or otherwise numeric type (float, double,
etc), then the numeric type should be chosen first, or ambiguity flagged
(your choice). The current behavior is as bad as if(); That's not
ambiguous, and follows the grammatical rules, why does that deserve a
special case and this not?
The real issue is do you want to have the implicit conversions:
0 => false
1 => true
or would you require a cast?
This is irrelevant to the problem. If one wants to pass a boolean
literal, they would use true or false, not cast(bool)1 or cast(bool)0.
When an implicit cast must be done, and overload selection is at stake,
bool should be last on the list of numeric types.
I think you are incorrectly making this into a "it has to be this way for
consistency" issue, it's not. It's an arbitrary rule, with very little
sense involved.
-Steve
