Overlapping functionality: IFTI, templates, is-expressions

[Bill Baxter]

Jason House wrote:
> Russell Lewis wrote:
> 
>> Jason House wrote:
>>> #2 I know from past discussions that C++ programmers hold this very near
>>> #and
>>> dear to their heart.  Personally, it seems like a back door to long
>>> compilation times.  I don't have any problem with enforcing criteria for
>>> templates to be defined up front, but I'm certain others don't agree with
>>> me.  Does the loss of SFINAE make templates too close to generics?  I
>>> know C# will refuse to compile code if the up-front criteria for a
>>> generic type isn't specific enough.
>> (quoting the Joker) "I have a name for my pain, and it is SFINAE!"
>>
>> Now I understand why dmd works (or actually, fails to work) the way it
>> does.  When I have some deeply-nested set of templates, and there is
>> some quirkly little problem deep within them, then dmd will often give
>> me some totally useless error:
>> foo.d: 25: template "wrapper_way_on_the_outside" has an error
>>
>> GRRRR!!!!  I thought that this was a bug in the compiler...
>>
>> The only way to debug these problems is to unwrap the template, by hand,
>> using repeated aliases over and over and over, dozens of compiles, until
>> you finally find the problem.  It's usually that some minor template way
>> off in the bowels of my library wasn't properly overloaded for some
>> specific case.
>>
>> void myFunctionThatWillNotCompile()
>> {
>> alias deepestNestedTemplate!(ARGS) a1;
>> alias nextLevel!(deepestNestedTemplate!(ARGS)) a2;
>> alias adNauseum!(...) a3;
>> /+
>> ... this code commented out because SFINAE makes
>> ... dmd produce error messages that don't tell me
>> ... what I need to know
>> +/
>> }
>>
>> Worse, it means that if I have a properly-specialized template for some
>> case, but the implementation within it has a small error, my code is
>> going to get routed to the general, catch-all template (which it never
>> should have hit), and the errors that I actually *do* see won't make any
>> sense.
>>
>> EEEK!!!
>>
>> I know that there must be a reason why people argue for SFINAE, but,
>> from my recent experience, I have to disagree.  I will say (with all
>> modestly and readiness to learn otherwise) that "SFINAE IS EVIL."
>>
>> Here's my modest proposal:
>> * If there is a "best match," force the code to use it.  Don't ignore
>> the best match because of internal compilation errors.
>> * If people really need SFINAE, then give them a way to express it
>> explicitly.  Something like:
>> template foo(int n)
>> {
>> static if(n == 0)
>> try_next_best_specialization;
>> }
> 
> 
> Making it explicit was discussed on the mailing list in the past (a few
> months ago?).  IIRC, nothing came of it.  

I think the main problem is that Walter basically hasn't ever spent time 
writing template-heavy code like this.  Remember it took a lot of 
convincing just to get him to agree that D needed templates at all. So a 
dozen people can tell him it's a good idea, but it's hard for him to 
verify this is so for himself, and adding features ad-hoc when people 
ask for them is clearly not a good design recipe.

--bb