Thread overview
template condition
Sep 27, 2012
Namespace
Sep 27, 2012
Timon Gehr
Sep 27, 2012
Andrej Mitrovic
Sep 27, 2012
Namespace
Sep 27, 2012
Namespace
Sep 27, 2012
Andrej Mitrovic
September 27, 2012
Is there any difference between these two code snippets:

#1:
struct Foo(T : Object) {

#2:
struct Foo(T) if (is(T == class)) {

?

I ask because I prefer option #1, but I see most often in Phobos variant #2.
September 27, 2012
On 09/27/2012 03:01 PM, Namespace wrote:
> Is there any difference between these two code snippets:
>
> #1:
> struct Foo(T : Object) {
>
> #2:
> struct Foo(T) if (is(T == class)) {
>
> ?
>
> I ask because I prefer option #1, but I see most often in Phobos variant
> #2.

Yes there is:

struct S{
    Object o;
    alias o this;
}

#1 accepts S, #2 does not.
September 27, 2012
On 9/27/12, Timon Gehr <timon.gehr@gmx.ch> wrote:
> snip

Perhaps he meant something like this:

struct Foo(T : Object) { }
struct Foo(T) if (is(T : Object )) { }

void main()
{
    Foo!Object x;
}

The difference is the first template is a specialization, and the second has a constraint. The first one will match better than the second one even though both templates can be instantiated with 'Object'.

The constraint version is more flexible but the specialization might be shorter to write.  http://dlang.org/template.html
September 27, 2012
Ok. And there is no performance difference? Just for the sake of completeness. :)
September 27, 2012
On Thu, 27 Sep 2012 11:34:15 -0400, Namespace <rswhite4@googlemail.com> wrote:

> Ok. And there is no performance difference? Just for the sake of completeness. :)

performance where?  Template instantiation is done at compile time.

The resulting code should be unaffected runtime-performance wise.

-Steve
September 27, 2012
On Thursday, 27 September 2012 at 15:39:39 UTC, Steven Schveighoffer wrote:
> On Thu, 27 Sep 2012 11:34:15 -0400, Namespace <rswhite4@googlemail.com> wrote:
>
>> Ok. And there is no performance difference? Just for the sake of completeness. :)
>
> performance where?  Template instantiation is done at compile time.
>
> The resulting code should be unaffected runtime-performance wise.
>
> -Steve

I mean: is there any difference by building the template? I don't understand what "more flexible" exactly mean.
September 27, 2012
On 9/27/12, Namespace <rswhite4@googlemail.com> wrote:
> I mean: is there any difference by building the template? I don't understand what "more flexible" exactly mean.

I mean you can create more complex constraints. See http://dlang.org/template.html
September 27, 2012
On Thu, 27 Sep 2012 11:46:05 -0400, Namespace <rswhite4@googlemail.com> wrote:

> On Thursday, 27 September 2012 at 15:39:39 UTC, Steven Schveighoffer wrote:
>> On Thu, 27 Sep 2012 11:34:15 -0400, Namespace <rswhite4@googlemail.com> wrote:
>>
>>> Ok. And there is no performance difference? Just for the sake of completeness. :)
>>
>> performance where?  Template instantiation is done at compile time.
>>
>> The resulting code should be unaffected runtime-performance wise.
>>
>> -Steve
>
> I mean: is there any difference by building the template? I don't understand what "more flexible" exactly mean.

The constraint basically is saying whether to instantiate the template or not, it has little to do with runtime performance.

Flexible means you have a full boolean logic you can use.

For example, if you had two unrelated objects A and B, how would you instantiate a template if the parameter derives from A *or* derives from B?

With a template constraint, that's:

template tmp(T) if(is(T : A) || is(T : B))

This is impossible to do with a specialization.

However, there are some limitations.  Template constraints don't cascade, while specializations do.

So while this:

template tmp(T) ...
template tmp(T : A)

works fine, this:

template tmp(T) ...
template tmp(T) if (is(T : A)) ...

does not, because it can instantiate both with an A.  Instead you have to do:

template tmp(T) if(!is(T : A)) ...
template tmp(T) if(is(T : A)) ...

It has been proposed to try and use else (if), but Walter didn't like it.

-Steve