1 matches bool, 2 matches long

[Steven Schveighoffer]

On Thu, 25 Apr 2013 23:01:30 -0700, Walter Bright  
<newshound2 at 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