digitalmars.D.bugs - [Issue 1951] New: Remove SFINAE
- d-bugmail puremagic.com (32/32) Mar 26 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1951
- d-bugmail puremagic.com (6/6) Mar 27 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1951
- d-bugmail puremagic.com (26/26) Nov 16 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1951
- d-bugmail puremagic.com (9/27) Nov 16 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1951
- d-bugmail puremagic.com (12/12) Dec 06 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1951
http://d.puremagic.com/issues/show_bug.cgi?id=1951 Summary: Remove SFINAE Product: D Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: jason.james.house gmail.com 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. --
Mar 26 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1951 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. --
Mar 27 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1951 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 main() { 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??? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=1951--------------- struct Test { alias int foo; } void main() { 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=1951 Jason House <jason.james.house gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID 05:51:51 PST --- I believe Don is right. D does not have SFINAE. Many D users simply assume that was inherited from C++. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 06 2012