Now that we're all talking about templates and Andrei is participating on this list, I figure it's a good time to bring this topic up again.

(brief background: SFINAE = substitution failure is not an error.  Commonly used when selecting which templated definition to apply.  Most uses in C++ are tricks to determine info available in D is expressions)

SFINAE causes debugging nightmares with template based code when a specialization fails to compile as expected.  When I challenged people in the past to provide real examples of template code that would require SFINAE in D, nobody could come up with one.  The template declaration and constraints in D seem to be enough.

I think we should try removing SFINAE from D 2.x while it's still considered experimental/alpha.  I expect a lack of SFINAE to make the compiler simpler and ensure D preserves its fast compile times.

If it does turn out that SFINAE does provide unique functionality, I think it may be better to enhance existing generic programming techniques than to keep SFINAE.  The further SFINAE gets pushed out of normal use (through constraints and detailed type declarations), the more of a corner case SFINAE becomes.  The more this happens, the more this "feature" will bite developers instead of helping them.

PS: This is basically a rehash of what I typed in http://d.puremagic.com/issues/show_bug.cgi?id=1951

It's also based on the past newsgroup thread at http://digitalmars.com/d/archives/digitalmars/D/SFINAE_is_Evil_67995.html

Jason House wrote:
> Now that we're all talking about templates and Andrei is participating on
> this list, I figure it's a good time to bring this topic up again.
> 
> (brief background: SFINAE = substitution failure is not an error.  Commonly
> used when selecting which templated definition to apply.  Most uses in C++
> are tricks to determine info available in D is expressions)
> 
> SFINAE causes debugging nightmares with template based code when a
> specialization fails to compile as expected.  When I challenged people in
> the past to provide real examples of template code that would require
> SFINAE in D, nobody could come up with one.  The template declaration and
> constraints in D seem to be enough.
> 
> I think we should try removing SFINAE from D 2.x while it's still considered
> experimental/alpha.  I expect a lack of SFINAE to make the compiler simpler
> and ensure D preserves its fast compile times.
> 
> If it does turn out that SFINAE does provide unique functionality, I think
> it may be better to enhance existing generic programming techniques than to
> keep SFINAE.  The further SFINAE gets pushed out of normal use (through
> constraints and detailed type declarations), the more of a corner case
> SFINAE becomes.  The more this happens, the more this "feature" will bite
> developers instead of helping them.
> 
> PS: This is basically a rehash of what I typed in
> http://d.puremagic.com/issues/show_bug.cgi?id=1951
> 
> It's also based on the past newsgroup thread at
> http://digitalmars.com/d/archives/digitalmars/D/SFINAE_is_Evil_67995.html

I think conditional templates obviate most, if not all, of the need for sfinae. There need to be some more steps taken, most importantly unification of regular functions with template functions.

Andrei@home

Andrei Alexandrescu wrote:

> I think conditional templates obviate most, if not all, of the need for sfinae. There need to be some more steps taken, most importantly unification of regular functions with template functions.
> 
> Andrei@home

Can you expand on the "unification of regular functions with template functions"?

On Sun, Oct 5, 2008 at 7:15 PM, Jason House <jason.james.house@gmail.com> wrote:
> Andrei Alexandrescu wrote:
>
>> I think conditional templates obviate most, if not all, of the need for sfinae. There need to be some more steps taken, most importantly unification of regular functions with template functions.
>>
>> Andrei@home
>
> Can you expand on the "unification of regular functions with template functions"?
>

So you can do i.e.

void foo(int x) {}
void foo(T)(T t) {}

foo(5) calls the int overload and foo(3.4) calls foo!(typeof(3.4))(3.4).

Jason House wrote:
> Andrei Alexandrescu wrote:
> 
>> I think conditional templates obviate most, if not all, of the need for
>> sfinae. There need to be some more steps taken, most importantly
>> unification of regular functions with template functions.
>>
>> Andrei@home
> 
> Can you expand on the "unification of regular functions with template
> functions"?

This is a large subject and I don't want to spread myself too thin. In
short:

void fun(int a, char[] b);

should be treated as if it were declared:

void fun(T, U)(T a, U b) if (is(T == int) && is(U == char[]));

In other words: a regular function is nothing but an "infinitely
specialized" template function.

Once that's in place, they'll all play rather nicely together. But there
are some more things to change, such as behavior of template functions
with implicit conversions.


Andrei

Jarrett Billingsley wrote:
> On Sun, Oct 5, 2008 at 7:15 PM, Jason House <jason.james.house@gmail.com> wrote:
>> Andrei Alexandrescu wrote:
>>
>>> I think conditional templates obviate most, if not all, of the need for
>>> sfinae. There need to be some more steps taken, most importantly
>>> unification of regular functions with template functions.
>>>
>>> Andrei@home
>> Can you expand on the "unification of regular functions with template
>> functions"?
>>
> 
> So you can do i.e.
> 
> void foo(int x) {}
> void foo(T)(T t) {}
> 
> foo(5) calls the int overload and foo(3.4) calls foo!(typeof(3.4))(3.4).

Thunder theft.

Andrei

On Sun, Oct 5, 2008 at 7:45 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Jason House wrote:
>>
>> Andrei Alexandrescu wrote:
>>
>>> I think conditional templates obviate most, if not all, of the need for sfinae. There need to be some more steps taken, most importantly unification of regular functions with template functions.
>>>
>>> Andrei@home
>>
>> Can you expand on the "unification of regular functions with template functions"?
>
> This is a large subject and I don't want to spread myself too thin. In short:
>
> void fun(int a, char[] b);
>
> should be treated as if it were declared:
>
> void fun(T, U)(T a, U b) if (is(T == int) && is(U == char[]));
>
> In other words: a regular function is nothing but an "infinitely specialized" template function.
>
> Once that's in place, they'll all play rather nicely together. But there are some more things to change, such as behavior of template functions with implicit conversions.

I was figuring this was how it would be unified.  Template specialization has more than enough power to do function overloading.

Andrei Alexandrescu:
> void fun(int a, char[] b);
> should be treated as if it were declared:
> void fun(T, U)(T a, U b) if (is(T == int) && is(U == char[]));
> 
> In other words: a regular function is nothing but an "infinitely specialized" template function.

So you can also take a delegate/function pointer of that fun() template.

Bye,
bearophile

On Sun, Oct 5, 2008 at 8:21 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Andrei Alexandrescu:
>> void fun(int a, char[] b);
>> should be treated as if it were declared:
>> void fun(T, U)(T a, U b) if (is(T == int) && is(U == char[]));
>>
>> In other words: a regular function is nothing but an "infinitely specialized" template function.
>
> So you can also take a delegate/function pointer of that fun() template.

There's nothing stopping you from taking the address of templated functions now, as long as they're fully specified.  Unless you're only talking about the syntactic benefits of being able to write &fun instead of &fun!(int, char[]).

Jarrett Billingsley wrote:
> On Sun, Oct 5, 2008 at 8:21 PM, bearophile <bearophileHUGS@lycos.com> wrote:
>> Andrei Alexandrescu:
>>> void fun(int a, char[] b);
>>> should be treated as if it were declared:
>>> void fun(T, U)(T a, U b) if (is(T == int) && is(U == char[]));
>>>
>>> In other words: a regular function is nothing but an "infinitely
>>> specialized" template function.
>> So you can also take a delegate/function pointer of that fun() template.
> 
> There's nothing stopping you from taking the address of templated
> functions now, as long as they're fully specified.  Unless you're only
> talking about the syntactic benefits of being able to write &fun
> instead of &fun!(int, char[]).

Yah, that's part of "But there are some more things to change". Ahem.

Andrei