www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "SFINAE is Evil"

reply Jason House <jason.james.house gmail.com> writes:
SFINAE - Substitution failure is not an error

This post is all about templates and their static if counterparts.  With the
enhanced expressiveness of D, is there a need for SFINAE from C++? 
Essentially, when a specialization exists, if the compilation of the
specialization fails, the compiler silently gives up on it and goes to the
next more general case.  In my mind, this is both dangerous and a loop hole
for long compile times (as the compiler instantiates extra template
instances).

What I want to know is this:  Who uses SFINAE in D, and why?  Is this a
matter of convenience or a requirement.  If required, I assume it's from a
lack of expressiveness in defining a template's conditions.  Could this be
overcome with use of static if's instead?

PS: Post title is a quote of Russell Lewis from another thread.
Mar 20 2008
next sibling parent "Craig Black" <craigblack2 cox.net> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:frv6ut$2ecv$1 digitalmars.com...
 SFINAE - Substitution failure is not an error

 This post is all about templates and their static if counterparts.  With 
 the
 enhanced expressiveness of D, is there a need for SFINAE from C++?
 Essentially, when a specialization exists, if the compilation of the
 specialization fails, the compiler silently gives up on it and goes to the
 next more general case.  In my mind, this is both dangerous and a loop 
 hole
 for long compile times (as the compiler instantiates extra template
 instances).

 What I want to know is this:  Who uses SFINAE in D, and why?  Is this a
 matter of convenience or a requirement.  If required, I assume it's from a
 lack of expressiveness in defining a template's conditions.  Could this be
 overcome with use of static if's instead?

 PS: Post title is a quote of Russell Lewis from another thread.
I get the feeling that a number of features in D can eventually be dumped in favor of others. Perhaps SFINAE is one of them. I haven't used templates in D enough to know for sure. Definitely worth discussing though IMO. Anything that reduces the complexity of D without sacrificing expressive power is a good thing. -Craig
Mar 20 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:
 SFINAE - Substitution failure is not an error
 
 This post is all about templates and their static if counterparts.  With the
 enhanced expressiveness of D, is there a need for SFINAE from C++? 
 Essentially, when a specialization exists, if the compilation of the
 specialization fails, the compiler silently gives up on it and goes to the
 next more general case.  In my mind, this is both dangerous and a loop hole
 for long compile times (as the compiler instantiates extra template
 instances).
 
 What I want to know is this:  Who uses SFINAE in D, and why?  Is this a
 matter of convenience or a requirement.  If required, I assume it's from a
 lack of expressiveness in defining a template's conditions.  Could this be
 overcome with use of static if's instead?
 
 PS: Post title is a quote of Russell Lewis from another thread.
How do I know if I'm using SFINAE or not? :-) Seriously, I might be using it. I'm not sure. I'm not sure how to go about checking. And that in and of itself seems like an undesirable quality. I will say that I have most definitely been bitten by errors that came from failure to instantiate the template I thought I was instantiating (most often due to IFTI failures). These things can usually be debugged by switching the code I suspect to specify all template arguments. Then I'll get the sensible error telling me why it doesn't match. Also I've had bugs from the is-expressions not getting triggered because I had a typo in the is-expression which wasn't a syntax error. Not sure how the compiler could help there, though. --bb
Mar 20 2008
parent Russell Lewis <webmaster villagersonline.com> writes:
Bill Baxter wrote:
 How do I know if I'm using SFINAE or not?  :-)
 
 Seriously, I might be using it.  I'm not sure.  I'm not sure how to go 
 about checking.  And that in and of itself seems like an undesirable 
 quality.
Indeed!
 I will say that I have most definitely been bitten by errors that came 
 from failure to instantiate the template I thought I was instantiating 
 (most often due to IFTI failures).  These things can usually be debugged 
 by switching the code I suspect to specify all template arguments.  Then 
 I'll get the sensible error telling me why it doesn't match.
Tuples hurt you here, because if you specify some Tuple template as a "last resort" template, you can end up using it for things you thought you'd handled. Or, at least, I think that maybe that's the case...with SFINAE, it's hard to know for sure.
Mar 21 2008
prev sibling next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
Jason House wrote:
 SFINAE - Substitution failure is not an error
 
 This post is all about templates and their static if counterparts.  With the
 enhanced expressiveness of D, is there a need for SFINAE from C++?
Here's a classic example of how SFINAE makes things hard. Look at the code below. You'd expect the static assert to fail, right? Give you an error message at the right location, and point you towards your bug? Nope. BEGIN CODE import std.stdio; template foo(TPL...) { static assert(false); } void main() { int i; foo!(i)(); } END CODE Here's what the compiler actually says: sfinae.d(3): template sfinae.foo(TPL...) is not a function template sfinae.d(11): template sfinae.foo(TPL...) cannot deduce template function from argument types !(i)() Not even a mention of the real problem. Now imagine that you are using non-trivial templates! Russ
Mar 21 2008
parent reply Jason House <jason.james.house gmail.com> writes:
It looks like your first compiler error is correct... There is no function.

 Jason House wrote:
 SFINAE - Substitution failure is not an error
 
 This post is all about templates and their static if counterparts.  With the
 enhanced expressiveness of D, is there a need for SFINAE from C++?
Here's a classic example of how SFINAE makes things hard. Look at the code below. You'd expect the static assert to fail, right? Give you an error message at the right location, and point you towards your bug? Nope. BEGIN CODE import std.stdio; template foo(TPL...) { static assert(false); } void main() { int i; foo!(i)(); } END CODE Here's what the compiler actually says: sfinae.d(3): template sfinae.foo(TPL...) is not a function template sfinae.d(11): template sfinae.foo(TPL...) cannot deduce template function from argument types !(i)() Not even a mention of the real problem. Now imagine that you are using non-trivial templates! Russ
Mar 21 2008
parent Russell Lewis <webmaster villagersonline.com> writes:
Jason House wrote:
 It looks like your first compiler error is correct... There is no 
function. You were right. I've seen that error so many times before, in cases, where a function did exist, that I didn't look closely enough. Here's a better example. The following code will produce useless "not a function template errors." Obviously, if you comment out the "static assert(false);", it works just fine. BEGIN dmd OUTPUT sfinae.d(3): template sfinae.foo(int I) is not a function template sfinae.d(22): template sfinae.foo(int I) cannot deduce template function from argument types !(5)() END OUTPUT BEGIN CODE import std.stdio; template foo(int I) { static if(I == 1) { void foo() {}; } else { void foo() { static assert(false); foo!(1)(); foo!(I-1)(); } } } void main() { foo!(5)(); } END CODE
Mar 24 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
I should probably expand this question...

Who uses templates in D? What is the most complex use you've done? Do you ever
plan to get more complex? Would SFINAE make your life easier or harder?

I've written templates classes that have one definition, and used static if as
needed for specialization. I don't forsee more complex usage and view SFINAE as
something that would mask bugs.



Jason House Wrote:

 SFINAE - Substitution failure is not an error
 
 This post is all about templates and their static if counterparts.  With the
 enhanced expressiveness of D, is there a need for SFINAE from C++? 
 Essentially, when a specialization exists, if the compilation of the
 specialization fails, the compiler silently gives up on it and goes to the
 next more general case.  In my mind, this is both dangerous and a loop hole
 for long compile times (as the compiler instantiates extra template
 instances).
 
 What I want to know is this:  Who uses SFINAE in D, and why?  Is this a
 matter of convenience or a requirement.  If required, I assume it's from a
 lack of expressiveness in defining a template's conditions.  Could this be
 overcome with use of static if's instead?
 
 PS: Post title is a quote of Russell Lewis from another thread.
Mar 21 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:
 I should probably expand this question...
 
 Who uses templates in D? What is the most complex use you've done? Do you ever
plan to get more complex? Would SFINAE make your life easier or harder?
 
 I've written templates classes that have one definition, and used static if as
needed for specialization. I don't forsee more complex usage and view SFINAE as
something that would mask bugs.
I don't have time to write more right now, but Lutz Kettner gives a pretty good examples of using SFINAE here: http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/meta.html#Constraining http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/meta.html#Classification Certainly the Enable_if template can be replaced by a simple static if. Maybe the other one too. The main problem I have with templates in D is that traits templates are severely limited by the inability to define specializations for a template in different modules. Like the IsVector_2 template Lutz talks about. If all specializations have to be in one file, then the library designer has to know in advance all the types that can ever be used as a Vector2 and clearly that limits the utility of it. Maybe this is coming in D2. I think I did a test recently and it still didn't work. --bb
Mar 22 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
I look forward to when you can write more... Are you trying to say SFINAE is
needed? I look at the examples and still think probably not. The traits example
can be solved cleanly in D, just like enable if. The toughest one is the vector
2 example. I think detection of what is a vector 2 could be done with an
interface? The rest of the examples I reaf are SFINAE free.


Bill Baxter Wrote:

 Jason House wrote:
 I should probably expand this question...
 
 Who uses templates in D? What is the most complex use you've done? Do you ever
plan to get more complex? Would SFINAE make your life easier or harder?
 
 I've written templates classes that have one definition, and used static if as
needed for specialization. I don't forsee more complex usage and view SFINAE as
something that would mask bugs.
I don't have time to write more right now, but Lutz Kettner gives a pretty good examples of using SFINAE here: http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/meta.html#Constraining http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/meta.html#Classification Certainly the Enable_if template can be replaced by a simple static if. Maybe the other one too. The main problem I have with templates in D is that traits templates are severely limited by the inability to define specializations for a template in different modules. Like the IsVector_2 template Lutz talks about. If all specializations have to be in one file, then the library designer has to know in advance all the types that can ever be used as a Vector2 and clearly that limits the utility of it. Maybe this is coming in D2. I think I did a test recently and it still didn't work. --bb
Mar 22 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
I was looking around for something good on traits templates, the hows 
and whys.
This seems to be pretty decent:
http://www.cantrip.org/traits.html

--bb
Mar 22 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
The description of traits in Boost is quite succinct and hits the good 
points -- particularly about the non-intrusive part:
http://www.boost.org/more/generic_programming.html#traits

I think most traits-like things can be done in D if you require that 
people modify their classes.  But the non-intrusiveness is one of key 
parts of what makes traits templates a good building block.

--bb
Mar 22 2008
parent Jason House <jason.james.house gmail.com> writes:
Bill Baxter Wrote:

 The description of traits in Boost is quite succinct and hits the good 
 points -- particularly about the non-intrusive part:
 http://www.boost.org/more/generic_programming.html#traits
 
 I think most traits-like things can be done in D if you require that 
 people modify their classes.  But the non-intrusiveness is one of key 
 parts of what makes traits templates a good building block.
 
 --bb
If D could load specializations in another module, generalized traits could be done in D. In fact, I'd argue that SFINAE would hide bugs in user-supplied template code.
Mar 22 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
 Bill Baxter Wrote:

 Jason House wrote:
 I should probably expand this question...

 Who uses templates in D? What is the most complex use you've done? 
Do you ever plan to get more complex? Would SFINAE make your life easier or harder?
 I've written templates classes that have one definition, and used 
static if as needed for specialization. I don't forsee more complex usage and view SFINAE as something that would mask bugs.
 I don't have time to write more right now, but
 Lutz Kettner gives a pretty good examples of using SFINAE here:
 
http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/meta.html#Constraining
 
http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/meta.html#Classification Jason House wrote:
 I look forward to when you can write more... Are you trying to say SFINAE is
needed? 
Yes, I'm saying I haven't yet found a case where I'm using it (but that doesn't mean there isn't one!) However, I did start a thread a while back about a way to introduce /controlled/ SFINAE. Or rather a way to explicitly say you want to try something, and if it does generate an error, try something else. Compile time try-catch. Look for the subject "static try catch construct would be helpful" in this newsgroup. I still think that would be useful.
 I look at the examples and still think probably not. 
Yes, with those examples I agree with you. They only use that Enable_if template which is easily replaced by a static if.
 The traits example can be solved cleanly in D, just like enable if. 
 The toughest one is the vector 2 example. I think detection of what 
is a vector 2 could be done with an interface? The rest of the examples I read are SFINAE free. Yes, well the vector2 one is the important one (but the parts that have to do with SFINAE aren't the problem). The traits templates can be thought of like compile-time adapters or facades. So they are like compile-time interfaces in a way. But they are non-intrusive. Fred provides library Foo. Barny provides type Bar. Wilma wants to use Barny's Bar with Fred's Foo, but Fred and Barney designed their code separately and the interfaces are compatible. So what traits templates do is give Fred's Foo a way to /ask Wilma/ what to do with Barney's Bar without having to get Barney involved. Wilma provides a FooTraits!(T:Bar) specialization, and Fred's Foo instantiates it and uses that to find out what it needs to know. Of course this presumes Fred designed Foo with this sort of flexibility in mind. Ok, so now that I've written all that out explicitly, I see that one nice but unessential thing about Traits as I've described them is that it operates in a "pull" manner. That is, when Wilma tries to create a Foo!(Bar), Foo just turns around and tries to instantiate a FooTraits!(Bar), which could come from anywhere (in C++ anyway), and in this case it comes from Wilma's code. So this can be worked around in D. It just requires switching to a "push" model. And that means the FooTraits must become an extra template parameter to Foo. So instead of Wilma just instantiating a Foo!(Bar) with the traits automatically ferreted out internally as FooTraits!(Bar), Wilma will need to explicitly pass the traits, like Foo!(Bar, WilmasFooTraitsForBar). So I guess it's not the end of the world. I can't think of any reason off the top of my head that using the push model would be a show stopper. It just isn't quite as slick. I guess it makes things difficult for function templates though. No IFTI if you have to provide a traits parameter explicitly. --bb
Mar 23 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter wrote:
 Jason House wrote:
 I look forward to when you can write more... Are you trying to say SFINAE
 is needed?
Yes, I'm saying I haven't yet found a case where I'm using it (but that doesn't mean there isn't one!) However, I did start a thread a while back about a way to introduce /controlled/ SFINAE. Or rather a way to explicitly say you want to try something, and if it does generate an error, try something else. Compile time try-catch. Look for the subject "static try catch construct would be helpful" in this newsgroup. I still think that would be useful.
I also had the feeling of "SFINAE is needed, but I can't come up with any examples". I find it interesting that nobody posted a need for SFINAE. Because of that, and all the pitfalls, I agree that SFINAE as a default behavior is undesirable and should disapear from D. Rather than propose an alternative to it, I wanted to understand how it should be used in D. With no examples of it, I've started leaning toward simple removal of it. I started this thread thinking the likely outcome would be something like your proposal. Now I'm thinking that SFINAE is not needed. If that's not true, I'm thinking it may be better to enhance is clauses and/or CTFE to cover the (small) capability gap. What do you think of that? If you (and others paying attention to this thread) agree, how do we get the attention of Walter? Maybe it should be a feature request or an entry on the unofficial D wishlist?
Mar 24 2008
parent reply Georg Wrede <georg nospam.org> writes:
Jason House wrote:
 I also had the feeling of "SFINAE is needed, but I can't come up with any
 examples".  I find it interesting that nobody posted a need for SFINAE. 
 Because of that, and all the pitfalls, I agree that SFINAE as a default
 behavior is undesirable and should disapear from D.
 
 Rather than propose an alternative to it, I wanted to understand how it
 should be used in D.  With no examples of it, I've started leaning toward
 simple removal of it.  I started this thread thinking the likely outcome
 would be something like your proposal.  Now I'm thinking that SFINAE is not
 needed.  If that's not true, I'm thinking it may be better to enhance is
 clauses and/or CTFE to cover the (small) capability gap.
 
 What do you think of that?  If you (and others paying attention to this
 thread) agree, how do we get the attention of Walter?  Maybe it should be a
 feature request or an entry on the unofficial D wishlist?
I suspect it would be quite simple to add a compiler switch to turn SFINAE on or off? Since D2 is "experimental" anyway, we might have this switch for a few months, and then see if anybody actually used it. The default would be SF is an error.
Mar 25 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Georg Wrede wrote:
 Jason House wrote:
 I also had the feeling of "SFINAE is needed, but I can't come up with any
 examples".  I find it interesting that nobody posted a need for 
 SFINAE. Because of that, and all the pitfalls, I agree that SFINAE as 
 a default
 behavior is undesirable and should disapear from D.

 Rather than propose an alternative to it, I wanted to understand how it
 should be used in D.  With no examples of it, I've started leaning toward
 simple removal of it.  I started this thread thinking the likely outcome
 would be something like your proposal.  Now I'm thinking that SFINAE 
 is not
 needed.  If that's not true, I'm thinking it may be better to enhance is
 clauses and/or CTFE to cover the (small) capability gap.

 What do you think of that?  If you (and others paying attention to this
 thread) agree, how do we get the attention of Walter?  Maybe it should 
 be a
 feature request or an entry on the unofficial D wishlist?
I suspect it would be quite simple to add a compiler switch to turn SFINAE on or off? Since D2 is "experimental" anyway, we might have this switch for a few months, and then see if anybody actually used it. The default would be SF is an error.
That would be great. I'd love to try out such a switch. Though at the moment it would do me no good unless it were added to D1 also. Though rather than turning it off, I'd rather have a -v kind of switch that prints out a message whenever SFINAE is invoked, maybe with an instantiation stack trace. --bb
Mar 25 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fsbp54$293h$1 digitalmars.com...

 That would be great.  I'd love to try out such a switch.  Though at the 
 moment it would do me no good unless it were added to D1 also.  Though 
 rather than turning it off, I'd rather have a -v kind of switch that 
 prints out a message whenever SFINAE is invoked, maybe with an 
 instantiation stack trace.
Great idea! <narrator>And with that, the suggestion began its slow, painful descent into the depths of the unread old posts of the NG, never to be seen again or commented on by the very man who could make a difference. Months later many would reminisce about what a good idea it was, and would sigh nostalgically over their youthful optimism.</narrator>
Mar 25 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Jarrett Billingsley wrote:

 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message
 <narrator>And with that, the suggestion began its slow, painful descent
 into the depths of the unread old posts of the NG, never to be seen again
 or
 commented on by the very man who could make a difference.  Months later
 many would reminisce about what a good idea it was, and would sigh
 nostalgically over their youthful optimism.</narrator>
That about sums it up :(
Mar 25 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:
 Jarrett Billingsley wrote:
 
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message
 <narrator>And with that, the suggestion began its slow, painful descent
 into the depths of the unread old posts of the NG, never to be seen again
 or
 commented on by the very man who could make a difference.  Months later
 many would reminisce about what a good idea it was, and would sigh
 nostalgically over their youthful optimism.</narrator>
That about sums it up :(
Yes, sweet. Someone should post a self-referential url in this thread so it will be easier to find and refer to it later. :-) --bb
Mar 25 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Jarrett Billingsley wrote:

 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message
 news:fsbp54$293h$1 digitalmars.com...
 
 That would be great.  I'd love to try out such a switch.  Though at the
 moment it would do me no good unless it were added to D1 also.  Though
 rather than turning it off, I'd rather have a -v kind of switch that
 prints out a message whenever SFINAE is invoked, maybe with an
 instantiation stack trace.
Great idea! <narrator>And with that, the suggestion began its slow, painful descent into the depths of the unread old posts of the NG, never to be seen again or commented on by the very man who could make a difference. Months later many would reminisce about what a good idea it was, and would sigh nostalgically over their youthful optimism.</narrator>
gain visibility with Walter (and more importantly?) Andrei, who's been known to fully flex C++'s templates. Feel free to add individual ideas on what might be a good alternative to SFINAE. I really didn't put any in the enhancement request.
Mar 26 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
 
 I don't have time to write more right now, but
 Lutz Kettner gives a pretty good examples of using SFINAE here:
 http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/me
a.html#Constraining 
 
 http://www.mpi-inf.mpg.de/~kettner/courses/lib_design_03/notes/meta
html#Classification 
 
 
Upon reading that, it's amazing how much more simple(and powerful) meta-programming is in D. (having static if, is-expressions, aliases, and D template syntax) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 26 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Jason House wrote:
 I should probably expand this question...
 
 Who uses templates in D? What is the most complex use you've done? Do you ever
plan to get more complex? Would SFINAE make your life easier or harder?
Templates are utterly necessary and horribly untestable. I use them, but I try to keep them as braindead simple as possible. I've done a reasonable amount of work with simple templates, eg DUnit's assertions, and some slightly more complex stuff, as with DMocks, but nothing incredibly difficult. DMocks was mainly a matter of looping through reflection information and assembling some strings based on that, which wasn't so difficult; the hardest thing (besides debugging CTFE failures and oddities with mixins, but I did my best to limit the amount of both) was not being able to have a variable whose type was an empty tuple. I had to wrap the tuple in a templated class that would just not instantiate the arguments variable with an empty tuple. SFINAE isn't a problem for me -- I don't need to overload templates much. If I did, I'd do it like this: template Foo(T, U, V...) { static if (condition1) { alias FooSpecialization1!(T, U, V) Foo; } else // ... } The only thing the compiler could do to help me that it isn't doing is to make it an error to have overloaded templates.
 I've written templates classes that have one definition, and used static if as
needed for specialization. I don't forsee more complex usage and view SFINAE as
something that would mask bugs.
Same. The only issue is with templates from different modules or libraries. In this case, it could be helpful for the compiler to have an error message along the lines of: template instantiation Foo!(int, float, float, char[]): could not instantiate. Candidates are: valhalla.odin.Foo(T : long, U, T, V[char]) : char[] is not a V[char] valhalla.thor.Foo(T : class, U...) : int is not a class ...
Mar 22 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Ok, so you're saying you could do without SFINAE?

Christopher Wright Wrote:

 Jason House wrote:
 I should probably expand this question...
 
 Who uses templates in D? What is the most complex use you've done? Do you ever
plan to get more complex? Would SFINAE make your life easier or harder?
Templates are utterly necessary and horribly untestable. I use them, but I try to keep them as braindead simple as possible. I've done a reasonable amount of work with simple templates, eg DUnit's assertions, and some slightly more complex stuff, as with DMocks, but nothing incredibly difficult. DMocks was mainly a matter of looping through reflection information and assembling some strings based on that, which wasn't so difficult; the hardest thing (besides debugging CTFE failures and oddities with mixins, but I did my best to limit the amount of both) was not being able to have a variable whose type was an empty tuple. I had to wrap the tuple in a templated class that would just not instantiate the arguments variable with an empty tuple. SFINAE isn't a problem for me -- I don't need to overload templates much. If I did, I'd do it like this: template Foo(T, U, V...) { static if (condition1) { alias FooSpecialization1!(T, U, V) Foo; } else // ... } The only thing the compiler could do to help me that it isn't doing is to make it an error to have overloaded templates.
 I've written templates classes that have one definition, and used static if as
needed for specialization. I don't forsee more complex usage and view SFINAE as
something that would mask bugs.
Same. The only issue is with templates from different modules or libraries. In this case, it could be helpful for the compiler to have an error message along the lines of: template instantiation Foo!(int, float, float, char[]): could not instantiate. Candidates are: valhalla.odin.Foo(T : long, U, T, V[char]) : char[] is not a V[char] valhalla.thor.Foo(T : class, U...) : int is not a class ...
Mar 22 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Jason House wrote:
 Ok, so you're saying you could do without SFINAE?
Yes, and I wish I could do without templates.
Mar 22 2008
parent Georg Wrede <georg nospam.org> writes:
Christopher Wright wrote:
 Jason House wrote:
 
 Ok, so you're saying you could do without SFINAE?
Yes, and I wish I could do without templates.
I don't need templates. But that's probably because I only do apps. If I were to write libraries (even for myself), then I'd expect to be using templates in many, if not most of the functions. I's just that I currently don't run into things where I'd need a template. As for SFINAE, I can't even imagine where I'd gain with it.
Mar 25 2008