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

[Walter Bright]

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.


>> 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.