Short list with things to finish for D2

[grauzone]

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> The rewrite is done long after lexing, so no low-level problems there.
>>
>> Oh, I thought it would let you introduce new operators. But it's only 
>> about the existing ones.
>>
>> I find the idea to identify the operator using a string very sloppy 
>> and sillyl just like using string mixins for small delegates in 
>> std.algorithm etc.; but you'd probably say "it works and is useful" 
>> and "it's short" and "it solves the current problem", so... whatever.
> 
> We're trying to improve on the current situation, which forces the user 
> to manually define a lot of small functions. If you have convincing 
> reasons to argue that the current state of affairs is actually better, 
> I'm all ears - both Walter and I could use less work, particularly if 
> the outcome sucks (see e.g. T[new]). Also, if you have ideas on how 
> things could be done in a way that you'd find not sloppy and not silly, 
> that would be even better.

If I had a better proposal, I'd post it. I'm just saying that's it's a 
bad hack, that _although_ solves the problem, will have negative side 
effects for other reasons.

Does the current proposal make things simpler at all? All you're doing 
is to enable the programmer to "fix" the clumsy semantics by throwing 
lots of CTFE onto the problem. Why not generate the operator functions 
with CTFE in the first place...