Comment #0 by jason.james.house — 2008-03-26T17:41:34Z
I can imagine the request sounding almost crazy, but it really isn't.
(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)
I've been polling people on the D mailing list and those I know who are deep into C++, and so far nobody can come up with a real-world use for SFINAE that can't be done with other mechanisms already in D (is expressions, static if, etc...)
What I have been able to find out from people is that SFINAE does cause debugging nightmares with template based code when a specialization fails to compile as expected.
I think trying no SFINAE is a great thing to try in 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 expect Andrei may know), 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, the more of a corner case it becomes... biting developers more often than it helps them.
Comment #1 by wbaxter — 2008-03-27T03:26:42Z
A good suggestion made on the newsgroups was to first add a switch to D2 for a while that can be used to either disable SFINAE or to print out a trace message every time the compiler uses it.
Comment #2 by clugdbug — 2012-11-16T00:33:22Z
Here's the first example from
http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error
translated into D.
---------------
struct Test {
alias int foo;
}
void f(T)(T.foo x) {} // Definition #1
void f(T)(T x) {} // Definition #2
void main() {
f!(Test)(10); // Call #1.
f!(int)(10); // C++ No error (even though there is no int::foo) thanks to SFINAE.
}
------------
bug.d(5): Error: no property 'foo' for type 'int'
bug.d(5): Error: T.foo is used as a type
------------
Same thing with every other SFINAE example I've been able to find. The behaviour is the same on D1 and D2.
Does D actually have SFINAE???
Comment #3 by k.hara.pg — 2012-11-16T00:53:12Z
(In reply to comment #2)
> ---------------
> struct Test {
> alias int foo;
> }
>
> void f(T)(T.foo x) {} // Definition #1
>
> void f(T)(T x) {} // Definition #2
>
> void main() {
> f!(Test)(10); // Call #1.
> f!(int)(10); // C++ No error (even though there is no int::foo) thanks to
> SFINAE.
> }
> ------------
> bug.d(5): Error: no property 'foo' for type 'int'
> bug.d(5): Error: T.foo is used as a type
> ------------
I think that is not a lack SFINAE, rather the type deduction mechanism issue.
In current, T.foo is not treated as a *partially parameterized* type name.
I recently filed bug 9022 to support such type deduction.
Comment #4 by jason.james.house — 2012-12-06T05:51:51Z
I believe Don is right. D does not have SFINAE. Many D users simply assume that was inherited from C++.