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.
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.
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???
(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.
I believe Don is right. D does not have SFINAE. Many D users simply assume that was inherited from C++.