mixin + CTFE, to big a hammer??

[Andrei Alexandrescu (See Website For Email)]

kris wrote:
> BCS wrote:
>> I have been thinking about the new functionality added by the code 
>> mixin and CTFE features and I'm thinking that they may be "to big a 
>> hammer" for may jobs.
>>
>> Take my parser generator as an example. I don't think there would be 
>> anything to gain by using mixin as the primary method of code 
>> generation. Firstly, code generated this way will inherently be harder 
>> to read and debug. Also it doesn't do anything that tuple iteration 
>> doesn't do just as well.
>>
>> I will admit that there may be some things to be gained there by using 
>> mixin code (the terminal and action call backs could benefit a lot 
>> from this) but these are only minor changes. Also mixin code would be 
>> invaluable for some more complicated cases.
>>
>> Why is this important? I think that many valuable types of code 
>> generation would benefit more by improving the static control 
>> structures (foreach/if/etc.) than they would from more mixin like 
>> features.
>>
>> One feature I would like is a true static foreach, one that can 
>> iterate over any built in type arrays or a tuple but does unrolling 
>> and per-loop semantic analysis like with tuples. This, in conjunction 
>> with CTFE, would make for huge improvements in what can readily be 
>> accomplished by moving much of the processing of the code generator 
>> input into function and out of templates.
>>
>> Basically, I'm saying that while mixin+CTFE is good from many things, 
>> it shouldn't be pushed at the expense of the more mundane techniques.
>>
>> Just some thoughts, what do you all think?
> 
> 
> D mixin, in it's current guise, is about equivalent to crack-cocaine. 
> Easily the worst thing that happened to the language, IMO.
> 
> Just say no

...to unbacked arguments. What is exactly the base for comparing D's 
mixins with crack-cocaine?

Andrei