http://d.puremagic.com/issues/show_bug.cgi?id=8441

           Summary: function expected, not <my function>
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: ellery-newcomer@utulsa.edu


--- Comment #0 from Ellery Newcomer <ellery-newcomer@utulsa.edu> 2012-07-25 14:06:24 PDT ---
code:

mixin template T(string i) {
    auto j(string s="a", U)(U u1, U u2) {
        return 0;
    }
    auto j(int i,string s="a", W)(W u1, W u2) {
        return i;
    }

    mixin("
    class F" ~ i ~ " {
    auto j(string s=\"a\", U)(U u1, U u2) {
        return this.outer.t" ~ i ~ ".j!(s,U)(u1,u2);
    }
    auto j(int i,string s=\"a\", W)(W u1, W u2) {
        return this.outer.t" ~ i ~ ".j!(i,s,W)(u1,u2); <- dmd is giving error
for j!(...).j's type
    }
    }
    auto f"~i~"() {
        return new F"~i~"();
    }
    ");

}

class X {
    mixin T!("1") t0;
    alias t0 t1;
}
void main (){
    X x = new X();
    x.f1().j!(3,"a")(2.2, 3.3);
}


fireworks:

tok.d(15): Error: function expected before (), not 'this.this.j!(3,"a",double)'
tok.d(31): Error: template instance tok.X.T!("1").F1.j!(3,"a",double) error
instantiating

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441


jfanatiker@gmx.at changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfanatiker@gmx.at


--- Comment #1 from jfanatiker@gmx.at 2012-11-20 07:31:13 PST ---
Can also reproduced with: https://github.com/eskimor/phobos/blob/new_signal/std/signals.d

And is currently a blocker for a full signals2 implementation.

Without it, I can only provide the FullSignal struct, which is good but does not support easily restriction of access to emit(). So users would have to redundantly create boilerplate code. Another option would be to use string mixins, but the syntax would not be as nice, so I would like to stick with the current implementation.

To summarize the problem: A mixin seems not to work with methods that are templates themselves, resulting in strange errors like:

std/signals.d(730): Error: no overload matches for disconnect(string
method,ClassType)

or

std/signals.d(633): Error: function expected before (), not
'a.connect!("watch")'

Tested with dmd 2.060 and current master
(7c370f71641c4408ddc9ebd5709e6e182e34ad2b).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441


jfanatiker@gmx.at changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441


monarchdodra@gmail.com changed:

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


--- Comment #2 from monarchdodra@gmail.com 2013-01-18 06:07:40 PST ---
It would appear the problem lies between a combination of mixin identifier, and template overload:

Here is a reduced test case:
//----
mixin template T() {
   void k()(){}

   void j()(){}
   void j(int i)(){}
}
class X
{
   mixin T t0;
}
void main (){
   X x;
   x.k!()();    //Fine
   x.j!()();    //Fine
   x.t0.k!()(); //Fine
   x.t0.j!()(); //Derp
}
//----
main.d(12): Error: function expected before (), not 'x.j!()'
//-----

(In reply to comment #1)
> Can also reproduced with: https://github.com/eskimor/phobos/blob/new_signal/std/signals.d
> 
> And is currently a blocker for a full signals2 implementation.

I don't know how you are affected by this, but you can workaround the problem by avoiding the template overload ambiguity. For example, this seems to work:

//----
mixin template T(string i) {

    private {
        auto j1(string s="a", U)(U u1, U u2) {
            return j!(s, U)(u1, u2);
        }
        auto j2(int i,string s="a", W)(W u1, W u2) {
            return j!(i, s, W)(u1, u2);
        }
    }

    auto j(string s="a", U)(U u1, U u2) {
        return 0;
    }
    auto j(int i,string s="a", W)(W u1, W u2) {
        return i;
    }

    mixin("
    class F" ~ i ~ " {
    auto j(string s=\"a\", U)(U u1, U u2) {
        return this.outer.t" ~ i ~ ".j1!(s,U)(u1,u2);
    }
    auto j(int i,string s=\"a\", W)(W u1, W u2) {
        return this.outer.t" ~ i ~ ".j2!(i,s,W)(u1,u2);
    }
    }
    auto f"~i~"() {
        return new F"~i~"();
    }
    ");

}

class X {
    mixin T!("1") t0;
    alias t0 t1;
}
void main (){
    X x = new X();
    x.f1().j!(3,"a")(2.2, 3.3);
}
//----

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441



--- Comment #3 from jfanatiker@gmx.at 2013-01-18 07:04:59 PST ---
Ah, I see: So the issue is that template overloads don't work. Thanks for investigating this!

Unfortunately it does not really help for std.signals2, because renaming the methods to connectDirectly, connectViaDelegate, .... seems rather ugly, although I don't think it is a good idea to alter a public API because of workarounds. I would be fine, if it only affected private parts.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441



--- Comment #4 from monarchdodra@gmail.com 2013-01-18 08:15:53 PST ---
(In reply to comment #3)
> Ah, I see: So the issue is that template overloads don't work.

In the context of template mixins with mixinIdentifiers only. Template overloads, as a general rule, do work.

> Thanks for
> investigating this!
> 
> Unfortunately it does not really help for std.signals2, because renaming the methods to connectDirectly, connectViaDelegate, .... seems rather ugly, although I don't think it is a good idea to alter a public API because of workarounds. I would be fine, if it only affected private parts.

Technically, I didn't rename anything. I merelly added some extra functions to remove the ambiguity in the context of the mixin identifier.

Yes, it is ugly, but the public interface is intact.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441



--- Comment #5 from jfanatiker@gmx.at 2013-01-18 09:17:10 PST ---
> In the context of template mixins with mixinIdentifiers only. Template overloads, as a general rule, do work.

Yeah, I meant that. I used to think that template functions in a mixin template don't work, but it is just overloads. Thanks for pointing this out.

> > Unfortunately it does not really help for std.signals2, because
> renaming the
> > methods to connectDirectly, connectViaDelegate, .... seems rather
> ugly,
> > although I don't think it is a good idea to alter a public API
> because of
> > workarounds. I would be fine, if it only affected private parts.
> 
> Technically, I didn't rename anything. I merelly added some extra
> functions to
> remove the ambiguity in the context of the mixin identifier.
> 
> Yes, it is ugly, but the public interface is intact.

But the instantiation of a signal and the access:
mixin T!("1") t0;
alias t0 t1;
x.f1().j!(3,"a")(2.2, 3.3);

vs
mixin T!() t0;
x.t0.j!(3,"a")(2.2, 3.3);

would change, which is part of the public accessible API. If the workaround gets removed, people would have to adopt their code, which is kind of unacceptable for phobos.

Best regards,

Robert

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441



--- Comment #6 from monarchdodra@gmail.com 2013-01-18 09:49:28 PST ---
(In reply to comment #5)
> 
> But the instantiation of a signal and the access:
> mixin T!("1") t0;
> alias t0 t1;
> x.f1().j!(3,"a")(2.2, 3.3);
> 
> vs
> mixin T!() t0;
> x.t0.j!(3,"a")(2.2, 3.3);
> 
> would change, which is part of the public accessible API. If the workaround gets removed, people would have to adopt their code, which is kind of unacceptable for phobos.
> 
> Best regards,
> 
> Robert

I don't understand. You used to have:
mixin T!("1") t0;
alias t0 t1;
x.f1().j!(3,"a")(2.2, 3.3);

And I proposed something that worked with
mixin T!("1") t0;
alias t0 t1;
x.f1().j!(3,"a")(2.2, 3.3);

Nothing changed. Where did:
mixin T!() t0;
x.t0.j!(3,"a")(2.2, 3.3);

Come from?

All you should need is a private "man in the middle"...

Well, I don't have your end code, so I don't know how acceptable that is anyways. Good luck :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441



--- Comment #7 from jfanatiker@gmx.at 2013-01-18 10:39:34 PST ---
Ha! Sorry :-) I completely forgot about the example of Ellery Newcomer (And I
wondered already how you made up such an elaborate solution, from such a simple
problem ;-) ).
The code I am concerned with is:
https://github.com/eskimor/phobos/blob/new_signal/std/signals.d

The template mixin code in particular:
mixin template Signal(Args...)
{
    private final void emit( Args args )
    {
        full.emit(args);
    }
    final void connect(string method, ClassType)(ClassType obj) if(is(ClassType
== class) && __traits(compiles, {void delegate(Args)
dg=mixin("&obj."~method);}))
    {
        full.connect!method(obj);
    }
    final void connect(ClassType)(ClassType obj, void delegate(ClassType obj,
Args) dg) if(is(ClassType == class))
    {
        full.connect(obj, dg);
    }
    final void strongConnect(void delegate(Args) dg)
    {
        full.strongConnect(dg);
    }
    final void disconnect(string method, ClassType)(ClassType obj)
if(is(ClassType == class) && __traits(compiles, {void delegate(Args)
dg=mixin("&obj."~method);}))
    {
        full.disconnect!method(obj);
    }
    final void disconnect(ClassType)(ClassType obj, void delegate(ClassType,
T1) dg) if(is(ClassType == class))
    {
        full.disconnect(obj, dg);
    }
    final void disconnect(ClassType)(ClassType obj) if(is(ClassType == class))
    {
        full.disconnect(obj);
    }
    final void strongDisconnect(void delegate(Args) dg)
    {
        full.strongDisconnect(dg);
    }
    final ref RestrictedSignal!(Args) restricted() @property
    {
        return full.restricted;
    }
    private FullSignal!(Args) full;
}

Use case:

class Button {
 mixin Signal!() clicked;
 void click() {
   clicked.emit();
 }
}
import std.stdio;
void main() {
Button b=new Button;
b.clicked.strongConnect(() {writeln("I was clicked!");});
b.click();
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8441


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull, rejects-valid


--- Comment #8 from Kenji Hara <k.hara.pg@gmail.com> 2013-02-24 00:08:50 PST ---
I don't test std.signal2 module, but the two test cases work with my patch.

https://github.com/D-Programming-Language/dmd/pull/1660

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------