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
