https://issues.dlang.org/show_bug.cgi?id=17983

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=9999

--

https://issues.dlang.org/show_bug.cgi?id=17983

Mike <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slavo5150@yahoo.com

--- Comment #1 from Mike <slavo5150@yahoo.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=17983

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> ---
I tried it with HEAD and both orderings, it compiles without complaint.

--

https://issues.dlang.org/show_bug.cgi?id=17983

--- Comment #3 from Mike <slavo5150@yahoo.com> ---
Test here that reproduces there error.  Compiled with dmd-nightly: https://run.dlang.io/is/nfMGfG

--

https://issues.dlang.org/show_bug.cgi?id=17983

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #4 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=17983

--- Comment #5 from Mike <slavo5150@yahoo.com> ---
Taken from http://forum.dlang.org/post/ouhm8h$90q$1@digitalmars.com

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

--

https://issues.dlang.org/show_bug.cgi?id=17983

Mike <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #6 from Mike <slavo5150@yahoo.com> ---


*** This issue has been marked as a duplicate of issue 16099 ***

--