alias foo = (char c) => 1;
alias foo = (int i) => 4;
enum int e = 7;
static assert(foo(e) == 4); // fails
Comment #1 by slavo5150 — 2017-11-15T00:09:31Z
This doesn't appear to be a cast/conversion or overload problem. What's happening is the the compiler is keeping the first alias in lexical order, and ignoring any other aliases. i.e. the following works
alias foo = (int i) => 4; // Notice int overload is first
alias foo = (char c) => 1;
enum int e = 7;
static assert(foo(e) == 4);
The compiler should probably emit an error on the second alias as foo is being redefined, but it certainly shouldn't just silently ignore it.
Comment #2 by bugzilla — 2017-11-15T04:26:30Z
I tried it with HEAD and both orderings, it compiles without complaint.
I just updated to the latest HEAD, and I get the error. However, this really has nothing to do with overloading. This code
auto foo(char c) { return 1; };
auto foo(int i) { return 4; };
enum int e = 7;
static assert(foo(e) == 4); // fails
compiles just fine. The problem is that you have two aliases, and only one wins. All you have to do is flip the order of declaration of the aliases, and there is no error.
Either declaring two aliases with the same name should result in an error (which it does when you're not aliasing lambdas), or the aliases need to be treated as actual function overloads. Personally, I'm inclined to argue that it should just be an error and that if someone wants to do overloading, they should just declare actual functions rather than using an alias.
Comment #5 by slavo5150 — 2017-11-16T07:32:50Z
Taken from http://forum.dlang.org/post/[email protected]
<quote>
Some really weird stuff is going on with aliasing and function overloads in general.
If we change them from anonymous lambdas to actual functions:
auto lambda1(char c) { return 1; }
auto lambda2(int i) { return 4; }
alias foo = lambda1;
alias foo = lambda2;
void main()
{
assert(foo('a') == 1);
assert(foo(1) == 4);
}
Hey look, it all works!
Even if lambda1 and lambda2 are turned into templates, it works.
</quote>
Comment #6 by slavo5150 — 2017-11-18T13:00:35Z
*** This issue has been marked as a duplicate of issue 16099 ***