What Does Haskell Have to Do with C++?

[Don]

Andrei Alexandrescu wrote:
> Don wrote:
>> Jeremie Pelletier wrote:
>>> http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/ 
>>>
>>>
>>> Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
>>> its quite a read :)
>>
>> Yes, it is excellent. Two comments:
>> (1) Bartosz's D examples make me seriously question 'static foreach' 
>> which is scheduled for implementation (bugzilla 3377).
>> If implemented, it will be a source of frustration, since it will not 
>> be very usable inside templates. The ability to exit from a 'static 
>> foreach' is something which is possible with a 'return'-style syntax, 
>> but is not possible with the 'eponymous template hack'.
> 
> I think breaking early out of a static foreach is not necessary (but 
> indeed convenient) for writing good loops.
> 
>> (2) It seems pretty clear that we need to allow the eponymous trick to 
>> continue to work when more than one template member is present. I 
>> think everyone who's ever attempted template metaprogramming in D has 
>> proposed  it!
> 
> Yes, that was on the list for a long time. Bartosz even has participated 
> to many related discussions. I'm surprised the article made it seem an 
> unescapable matter of principles, when it clearly is a trivially fixable 
> bug in the language definition.

Yes, looking at the compiler source, it doesn't look too difficult.  The 
fact that something like this works:

template foo(int X)
{
    static if (bar!(X)) { const int foo = 57; }
    else { const char [] foo = "abc"; }
}
makes it pretty clear that the difficult part has already been done.

I don't know what happens with template mixins, though. I hate template 
mixins (and I'm not convinced they're useful for anything, either).

> We discussed using "this" instead of the template's name, but that has a 
> few ambiguity problems. Currently, we want to allow a template to define 
> private symbols in addition to the eponymous trick (a term that Bartosz 
> shouldn't have implied paternity of, sigh). Those private members would 
> be accessible from inside the template's definition, but not from the 
> outside. That would effectively remove the issue.
> 
> 
> Andrei