This question has first appeared on D.learn:

  http://forum.dlang.org/post/vlosugoeuobjrdfaeegk@forum.dlang.org

A simple program:

import std.stdio;

void foo(bool b)
{
    writeln("bool");
}

void foo(long l)
{
    writeln("long");
}

void main()
{
    foo(1);
    foo(2);
}

The program calls two separate foo() overloads for 1 and 2:

bool
long

According to the language spec, both overloads match the int argument by "implicit conversion" as described under "Function Overloading" here:

  http://dlang.org/function.html

Then, the overload must be resolved by partial ordering: "If two or more functions have the same match level, then partial ordering is used to try to find the best match. Partial ordering finds the most specialized function."

Is bool more specialized than long or is this a bug? Intuitively, both should match the 'long' overload. It feels like there should at least be ambiguity.

Ali

On 04/25/2013 11:05 PM, Ali Çehreli wrote:
> ...
>
> Is bool more specialized than long or is this a bug? Intuitively, both
> should match the 'long' overload.

bool is more specialized than long; you can pass any bool argument as a long argument, but not vice versa.

> It feels like there should at least be ambiguity.
> ...

This would be an enhancement. (A possible rule to add would be that literal-level conversions cannot influence the chosen overload.)

On 2013-04-25, 23:05, Ali Çehreli wrote:

> This question has first appeared on D.learn:
>
>    http://forum.dlang.org/post/vlosugoeuobjrdfaeegk@forum.dlang.org
>
> A simple program:
>
> import std.stdio;
>
> void foo(bool b)
> {
>      writeln("bool");
> }
>
> void foo(long l)
> {
>      writeln("long");
> }
>
> void main()
> {
>      foo(1);
>      foo(2);
> }
>
> The program calls two separate foo() overloads for 1 and 2:
>
> bool
> long
>
> According to the language spec, both overloads match the int argument by "implicit conversion" as described under "Function Overloading" here:
>
>    http://dlang.org/function.html
>
> Then, the overload must be resolved by partial ordering: "If two or more functions have the same match level, then partial ordering is used to try to find the best match. Partial ordering finds the most specialized function."
>
> Is bool more specialized than long or is this a bug? Intuitively, both should match the 'long' overload. It feels like there should at least be ambiguity.

For what it's worth, this is ambiguous in C++.


-- 
Simen

> Is bool more specialized than long

Yes, because a bool can be implicitly converted to a long, but a long cannot be implicitly converted to a bool.

On Friday, 26 April 2013 at 00:35:33 UTC, Walter Bright wrote:
>> Is bool more specialized than long
>
> Yes, because a bool can be implicitly converted to a long, but a long cannot be implicitly converted to a bool.

As we have bool literals as true and false, I don't think 1 should match bool in the first place.

Is is acceptable for 1 to match bool and 2 long? Maybe it is not acceptable in a serious language with strong typing...

Bye,
bearophile

On Thursday, 25 April 2013 at 21:05:43 UTC, Ali Çehreli wrote:
> This question has first appeared on D.learn:
>
> ...
>
> The program calls two separate foo() overloads for 1 and 2:
>
> bool
> long
>
> According to the language spec, both overloads match the int argument by "implicit conversion" as described under "Function Overloading" here:
>
>   http://dlang.org/function.html
>
> Then, the overload must be resolved by partial ordering: "If two or more functions have the same match level, then partial ordering is used to try to find the best match. Partial ordering finds the most specialized function."
>
> Is bool more specialized than long or is this a bug? Intuitively, both should match the 'long' overload. It feels like there should at least be ambiguity.
>
> Ali

Looks like value range propagation bug because 1 is integer literal and should be converted to long. There is no way for 1 to be converted to bool here (from TDPL long is below int and it is the shortest way, value range propagation can work upwards, but the path would be longer).

On 04/25/2013 06:44 PM, Maxim Fomin wrote:

> On Thursday, 25 April 2013 at 21:05:43 UTC, Ali Çehreli wrote:

> Looks like value range propagation bug because 1 is integer literal and
> should be converted to long. There is no way for 1 to be converted to
> bool here

That special conversion rule of literal 0 and literal 1 being implicitly convertible to false and true gets in the way.

> (from TDPL long is below int and it is the shortest way, value
> range propagation can work upwards, but the path would be longer).

Interesting.

I agree with bearophile, this is too surprising:

  foo(1);  // goes to bool

Decide to change the value:

  foo(2);  // now goes to long

Introduce a variable:

  int i = 1;
  foo(i);  // again, goes to long

I feel defeated. :)

Ali

On 4/26/13, Ali Çehreli <acehreli@yahoo.com> wrote:
> Introduce a variable:
>
>    int i = 1;
>    foo(i);  // again, goes to long

An even better example:

enum e = 1;
void main()
{
    foo(e);  // bool
}

static e = 1;
void main()
{
    foo(e);  // long
}

I find this unacceptable.

On Thursday, April 25, 2013 17:35:34 Walter Bright wrote:
> > Is bool more specialized than long
> 
> Yes, because a bool can be implicitly converted to a long, but a long cannot be implicitly converted to a bool.

However, given that bool isn't even an integral type, it seems very wrong that it would be a better match than something which _is_ an integral type. Given that the compiler already inserts explicit casts to bool in conditions to solve the primary case where you want a non-boolean value to implicitly convert to bool, it really seems to me that the other conversions to and from bool which are currently accepted are far too lax. Another example of this would be something like "foo" ~ true. I don't understand why conversions like that are allowed by the spec. They're just going to cause bugs.

- Jonathan M Davis