DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

aliak something at something.com
Wed Nov 14 06:56:12 UTC 2018


On Tuesday, 13 November 2018 at 09:17:51 UTC, Walter Bright wrote:
> On 11/13/2018 12:23 AM, aliak wrote:
>> Doesn't the above miss a step, and wouldn't it be:
>> 
>> 1) A.a => <implicit-convert-to-int><exact-match-on-f(int)>
>> 2) A.a => 
>> <implicit-convert-to-int><implicit-convert-to-short><exact-match-on-f(short)>
>> 
>> So basically for the f(short) path you have 3 steps instead of 
>> 2 for the f(int) path.
>> 
>> So does it matter how many implicit conversions need to happen 
>> before D stops trying? Or is it basically convert as long as 
>> you can? Does D actually do a "find the shortest path via 
>> implicit conversions to an overload" algorithm?
>
> It is not a shortest path algorithm. It's simply the enum is 
> converted to the base type and the base type is matched against 
> the parameter type.

Ok, thanks!
>
>
>>> One could have <implicit conversion><exact> be treated as 
>>> "better than" <implicit conversion><implicit conversion>, and 
>>> it sounds like a good idea, but even C++, not known for 
>>> simplicity, tried that and had to abandon it as nobody could 
>>> figure it out once the code examples got beyond trivial 
>>> examples.
>> 
>> Interesting. This seems simpler intuitively (shorter path, 
>> pick it), so I'm wondering if there're any links you can point 
>> to that describe what these problems were?
>
> No, I simply remember the discussions about it in the early 
> 90's. Yes, it seems to intuitively make sense, but if you look 
> at real C++ code and try to figure it out, it's a nightmare. 
> There can also be multiple paths of conversions, and loops in 
> those paths. There's a quadratic problem when there are 
> multiple parameters.

Bummer. At least if this enum : int case is fixed that doesn't 
seem like it's hard to work out in my head at least - but I guess 
I'm missing some edge case maybe, but I can't figure it out.

Pus, it seems to work as "expected" with alias this. So I kinda 
wonder what reasons there could be to not make it work as 
expected for other scenarios.

struct B {
     enum A : int { a }
     alias b = A.a;
     alias b this;
}

void f(short) {}
void f(int) {}

f(B()); // does what anyone would expect



More information about the Digitalmars-d-announce mailing list