www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template specialization and mixin templates

reply "Ben Gertzfield" <bgertzfield gmail.com> writes:
Hi folks,

I ran into what I think might be a bug with template 
specialization not applying when using a mixin template to 
specialize a function.

Here's an example:

http://pastebin.com/Wp96KHAY

The output I get with dmd v2.061 seems to show that the compiler 
only chooses a template specialization if a template mixin 
defines both the most general function as well as the specialized 
version.

In the example below, I would expect the second instance of 
Bar.go(T) to be MakeGo.go(T : U).

$ rdmd templateSpecialization.d
Foo.go(T)
Foo.go(T : int)
Bar.go(T)
Bar.go(T : int)
Bar.go(T)
MakeGo2.go(T)
MakeGo2.go(T : U)

I chatted with Andrei, and he suggested this behavior seemed like 
a bug. Anyway, the workaround is pretty easy (ensure we provide 
both the general and specialized implementation of the method 
when using a mixin template), but I wanted to send it to the 
group to see if I'm missing something.
Mar 29 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/29/2013 06:07 PM, Ben Gertzfield wrote:

 Hi folks,

 I ran into what I think might be a bug with template specialization not
 applying when using a mixin template to specialize a function.

 Here's an example:

 http://pastebin.com/Wp96KHAY

 The output I get with dmd v2.061 seems to show that the compiler only
 chooses a template specialization if a template mixin defines both the
 most general function as well as the specialized version.

 In the example below, I would expect the second instance of Bar.go(T) to
 be MakeGo.go(T : U).

 $ rdmd templateSpecialization.d
 Foo.go(T)
 Foo.go(T : int)
 Bar.go(T)
 Bar.go(T : int)
 Bar.go(T)
 MakeGo2.go(T)
 MakeGo2.go(T : U)

 I chatted with Andrei, and he suggested this behavior seemed like a bug.
 Anyway, the workaround is pretty easy (ensure we provide both the
 general and specialized implementation of the method when using a mixin
 template), but I wanted to send it to the group to see if I'm missing
 something.


It is not a bug.

The relevant part of dlang.org specification:

dlang.org/template-mixin.html:

Mixin Scope
The declarations in a mixin are ‘imported’ into the surrounding scope. 
If the name of a declaration in a mixin is the same as a declaration in 
the surrounding scope, the surrounding declaration overrides the mixin one:

int x = 3;

mixin template Foo() {
   int x = 5;
   int y = 5;
}

mixin Foo;
int y = 3;

void test() {
   writefln("x = %d", x);  // prints 3
   writefln("y = %d", y);  // prints 3
}
Mar 29 2013
parent "Ben Gertzfield" <bgertzfield gmail.com> writes:
On Friday, 29 March 2013 at 18:39:35 UTC, Timon Gehr wrote:


 The declarations in a mixin are ‘imported’ into the surrounding 
 scope. If the name of a declaration in a mixin is the same as a 
 declaration in the surrounding scope, the surrounding 
 declaration overrides the mixin one:


Surely that's not useful behavior for template specializations, 
though?

If we want this behavior to be part of the language, I think it 
should at the be a compiler warning or error, just like shadowing 
a variable.

It took me quite a while to pinpoint what was going wrong here.
Mar 29 2013