Thread overview
Template specialization and mixin templates
Mar 29, 2013
Ben Gertzfield
Mar 29, 2013
Timon Gehr
Mar 29, 2013
Ben Gertzfield
March 29, 2013
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.
March 29, 2013
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
}



March 29, 2013
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.