www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - mixin module template -> undefined identifier

reply Robert Schadek <realburner gmx.de> writes:
I have some found some irregular behavior when using mixins with
template and modules. If a aggregation is defined in the same module it
is found. If the aggregation is defined in another module it fails. And
I wonder if this is be design. For comparison see the code below.

// file: moduleA.d

module A;

public int func(T)() {
    return mixin(T.stringof ~ ".fun()");
}

struct Bar {
    static int fun() {
        return 2;
    }
}

unittest {
    static assert(func!Bar() == 2);
}


// file: moduleB.d

import A;

struct Foo {
    static int fun() {
        return 1;
    }
}

void main() {
    assert(func!Foo() == 1);
}

dmd moduleA.d moduleB.d -ofmix -unittest
moduleA.d(4): Error: undefined identifier Foo
moduleB.d(10): Error: template instance A.func!(Foo) error instantiating
Oct 03 2013
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote:
 // file: moduleA.d

 module A;

 public int func(T)() {
     return mixin(T.stringof ~ ".fun()");
 }

 […]

 dmd moduleA.d moduleB.d -ofmix -unittest
 moduleA.d(4): Error: undefined identifier Foo
 moduleB.d(10): Error: template instance A.func!(Foo) error 
 instantiating

Yes, this is indeed very much by design – A does not import B, so there is no reason why the name "Foo" should exist in A. To access the template parameter, just use it directly in the mixin (as in »mixin("T.fun()")«). I'm aware that the situation where you actually stumbled over this is probably a bit more complex, but in my experience an equivalent rewrite can almost always be performed quite easily once you have wrapped your head around the concept. Oh, and for those of you keeping track, this is another example supporting my stance that using "stringof" for code generation is (almost) always a bad idea. The fact that experienced D coders seem to run into this trap quite frequently, judging from the fact that is by far not the first NG thread on this topic, seems to suggest that we should address this with a big red warning in the documentation, probably where string mixins are discussed. (The recently merged pull request warning about .stringof use is a first step, albeit it does so for a different reason.) David
Oct 03 2013
prev sibling next sibling parent Robert Schadek <realburner gmx.de> writes:
On 10/03/2013 08:10 PM, David Nadlinger wrote:
 On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote:
 dmd moduleA.d moduleB.d -ofmix -unittest
 moduleA.d(4): Error: undefined identifier Foo
 moduleB.d(10): Error: template instance A.func!(Foo) error instantiating

Yes, this is indeed very much by design – A does not import B, so there is no reason why the name "Foo" should exist in A.

under the impression symbols would be seen when instantiated. I mean the error starts with A.func!(Foo) error instantiating.
 To access the template parameter, just use it directly in the mixin
 (as in »mixin("T.fun()")«). I'm aware that the situation where you
 actually stumbled over this is probably a bit more complex, but in my
 experience an equivalent rewrite can almost always be performed quite
 easily once you have wrapped your head around the concept.

code at compile time which I than mixin to have as good as handwritten code. I just found it odd that it works if I instantiate the template from the same module.
Oct 03 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--047d7b5d57ceb8560804e7e0ab63
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013/10/4 Robert Schadek <realburner gmx.de>

 On 10/03/2013 08:10 PM, David Nadlinger wrote:
 On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote:
 dmd moduleA.d moduleB.d -ofmix -unittest
 moduleA.d(4): Error: undefined identifier Foo
 moduleB.d(10): Error: template instance A.func!(Foo) error instantiati=



 Yes, this is indeed very much by design =E2=80=93 A does not import B, =


 there is no reason why the name "Foo" should exist in A.

under the impression symbols would be seen when instantiated. I mean the error starts with A.func!(Foo) error instantiating.
 To access the template parameter, just use it directly in the mixin
 (as in =C2=BBmixin("T.fun()")=C2=AB). I'm aware that the situation wher=


 actually stumbled over this is probably a bit more complex, but in my
 experience an equivalent rewrite can almost always be performed quite
 easily once you have wrapped your head around the concept.

code at compile time which I than mixin to have as good as handwritten code. I just found it odd that it works if I instantiate the template from the same module.

Using built-in 'stringof' property for code generation won't work in general. Instead: public int func(T)() { return mixin("T" ~ ".fun()"); } Kenji Hara --047d7b5d57ceb8560804e7e0ab63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /10/4 Robert Schadek <span dir=3D"ltr">&lt;<a href=3D"mailto:realburner gmx= .de" target=3D"_blank">realburner gmx.de</a>&gt;</span><br><blockquote clas= s=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0p= x;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204= );border-left-style:solid;padding-left:1ex"> <div class=3D"im">On 10/03/2013 08:10 PM, David Nadlinger wrote:<br> &gt; On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote:<br> &gt;&gt;<br> </div><div class=3D"im">&gt;&gt; dmd moduleA.d moduleB.d -ofmix -unittest<b= r> &gt;&gt; moduleA.d(4): Error: undefined identifier Foo<br> &gt;&gt; moduleB.d(10): Error: template instance A.func!(Foo) error instant= iating<br> &gt;<br> &gt; Yes, this is indeed very much by design =E2=80=93 A does not import B,= so<br> &gt; there is no reason why the name &quot;Foo&quot; should exist in A.<br> </div>Yes, it does not exists in the module but func is a template and I wa= s<br> under the impression symbols would be seen when instantiated. I mean the<br=

<div class=3D"im">&gt;<br> &gt; To access the template parameter, just use it directly in the mixin<br=

situation where you<br> &gt; actually stumbled over this is probably a bit more complex, but in my<= br> &gt; experience an equivalent rewrite can almost always be performed quite<= br> &gt; easily once you have wrapped your head around the concept.<br> </div>Not as easy to fix this as I have a library that generates me sqlite<= br> code at compile time which I than mixin to have as good as handwritten<br> code. I just found it odd that it works if I instantiate the template<br> from the same module.<br></blockquote><div><br></div><div>Using built-in &#= 39;stringof&#39; property for code generation won&#39;t work in general. In= stead:</div><div><br></div><div><div>public int func(T)() {</div><div> =C2=A0 =C2=A0 return mixin(&quot;T&quot; ~ &quot;.fun()&quot;);</div><div>}= </div><div>=C2=A0<br></div></div><div>Kenji Hara</div></div></div></div> --047d7b5d57ceb8560804e7e0ab63--
Oct 03 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 3 October 2013 at 18:39:48 UTC, Robert Schadek wrote:
 Yes, it does not exists in the module but func is a template 
 and I was
 under the impression symbols would be seen when instantiated.

No. D doesn't have something like C++'s ADL where the template arguments lead to additional names being introduced into the scope of the template body. This is by design.
 I mean the
 error starts with A.func!(Foo) error instantiating.

Sorry, I don't quite get what you mean here. The error is just a follow-up to the previous one, as the inability to look up Foo caused an error while instantiating that template.
 Not as easy to fix this as I have a library that generates me 
 sqlite
 code at compile time which I than mixin to have as good as 
 handwritten
 code. I just found it odd that it works if I instantiate the 
 template
 from the same module.

Maybe you can elaborate a bit on how the problem occurs in that context? As I said, I've found that usually it is possible to come up with a design at least as pretty (or even prettier) but doesn't rely on stringof trickery if one just stares at the problem long enough. ;) David
Oct 03 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
By spec name resolution for templates happens in declaration 
scope. Mixin templates are only exception.

If referencing symbol from other module during code gen is a 
unavoidable necessity, you should use instrospection on `T` and 
add its module into code gen as template-local import (something 
like 
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/restutil.d#L341)
Oct 04 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
P.S. I have tried contacting you in context of std.logger, is 
mail address mentioned on github valid one? If not, please ping 
me via public.dicebot.lv
Oct 04 2013
prev sibling next sibling parent Robert Schadek <realburner gmx.de> writes:
On 10/04/2013 09:07 AM, Dicebot wrote:
 P.S. I have tried contacting you in context of std.logger, is mail
 address mentioned on github valid one? If not, please ping me via
 public.dicebot.lv

Oct 04 2013
prev sibling parent Robert Schadek <realburner gmx.de> writes:
On 10/04/2013 04:36 AM, David Nadlinger wrote:
 Maybe you can elaborate a bit on how the problem occurs in that
 context? As I said, I've found that usually it is possible to come up
 with a design at least as pretty (or even prettier) but doesn't rely
 on stringof trickery if one just stares at the problem long enough. ;)

I will try to find a way around.
Oct 04 2013