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

Adam D. Ruppe <destructionator@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |destructionator@gmail.com

--- Comment #1 from Adam D. Ruppe <destructionator@gmail.com> ---
That's not a bug, that's by design. It allows you to override an overload set from a mixin template while keeping the other things.

To merge the sets, you use alias:

struct S {
    mixin Operators ops;
    int opBinary(string op: "*")(S rhs) {return 2;}
    alias opBinary = ops.opBinary;
}


However, while that works with every other case, with this one.... it is giving me

Error: alias `ooooo.S.opBinary` conflicts with template ooooo.S.opBinary(string
op : "*")(S rhs) at ooooo.d(7)


So that *might* be a bug, it isn't merging specialized templates... I was going to close this immediately, but maybe this specific thing is legit.

To work around that, offer a dispatcher function instead of an alias:


struct S {
    mixin Operators ops;
    int opBinary(string op: "*")(S rhs) {return 2;}
    int opBinary(string op)(S rhs) {
        // forward all others to the mixin
        return ops.opBinary!op(rhs);
    }
}


see for design: https://dlang.org/spec/template-mixin.html#mixin_scope

--

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

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86                         |All
            Summary|operator overloading set of |Allow aliasing templated
                   |mixin template is not       |functions from mixin
                   |considered                  |template to add them to
                   |                            |overload set
                 OS|Windows                     |All
           Severity|normal                      |enhancement

--- Comment #2 from Dennis <dkorpel@live.nl> ---
(In reply to Adam D. Ruppe from comment #1)
> So that *might* be a bug, it isn't merging specialized templates... I was going to close this immediately, but maybe this specific thing is legit.

Thanks for the workaround.

--

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

--- Comment #3 from Dennis <dkorpel@live.nl> ---
(In reply to Adam D. Ruppe from comment #1)
> So that *might* be a bug, it isn't merging specialized templates... I was going to close this immediately, but maybe this specific thing is legit.

I also noticed that it matters whether you put the alias before or after the new opBinary method.

Anyway, I'll change this to an enhancement, thanks for the workaround. (I happily replace the ugly string mixin with a dispatcher function.)

--

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

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qs.il.paperinik@gmail.com

--- Comment #4 from Bolpat <qs.il.paperinik@gmail.com> ---
(In reply to Adam D. Ruppe from comment #1)
> That's not a bug, that's by design. It allows you to override an overload set from a mixin template while keeping the other things.

This hasn't to do with overload sets. Overload sets work are separated overloads to search for matches where an ambiguity error occurs when there are any matches in two or more sets, regardless whether one match is clearly better.

The symbols inserted by mixin templates are always completely shadowed by eponymous symbols in the same scope. ALWAYS. The case Dennis describes is where the mixed-in symbol is the only one that could match. The error isn't an ambiguity error, so this is not primarily about overload sets, but symbol shadowing. This is intentional.

The enhancement therefore boils down to proposing against the current way of shadowing and for overloading sets. Putting the mixed-in symbols in a named scope like you're suggesting actually creates overloading sets in the first place.

There is a good reason for the shadowing, so this enhancement probably isn't going anywhere.

--

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

--- Comment #5 from Dennis <dkorpel@live.nl> ---
(In reply to Bolpat from comment #4)
> Overload sets work are separated overloads to search for matches where an ambiguity error occurs when there are any matches in two or more sets, regardless whether one match is clearly better.

I don't understand this sentence.

> Putting the mixed-in symbols in a named
> scope like you're suggesting actually creates overloading sets in the first
> place.
> 
> There is a good reason for the shadowing, so this enhancement probably isn't going anywhere.

The suggestion is not to change mixin template behavior, it is to allow using `alias` to explicitly combine mixin methods with existing member functions.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--