Short list with things to finish for D2

[Lars T. Kyllingstad]

Andrei Alexandrescu wrote:
> We're entering the finale of D2 and I want to keep a short list of 
> things that must be done and integrated in the release. It is clearly 
> understood by all of us that there are many things that could and 
> probably should be done.
> 
> 1. Currently Walter and Don are diligently fixing the problems marked on 
> the current manuscript.
> 
> 2. User-defined operators must be revamped. Fortunately Don already put 
> in an important piece of functionality (opDollar). What we're looking at 
> is a two-pronged attack motivated by Don's proposal:
> 
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
> 
> The two prongs are:
> 
> * Encode operators by compile-time strings. For example, instead of the 
> plethora of opAdd, opMul, ..., we'd have this:
> 
> T opBinary(string op)(T rhs) { ... }
> 
> The string is "+", "*", etc. We need to design what happens with 
> read-modify-write operators like "+=" (should they be dispatch to a 
> different function? etc.) and also what happens with index-and-modify 
> operators like "[]=", "[]+=" etc. Should we go with proxies? Absorb them 
> in opBinary? Define another dedicated method? etc.
> 
> * Loop fusion that generalizes array-wise operations. This idea of 
> Walter is, I think, very good because it generalizes and democratizes 
> "magic". The idea is that, if you do
> 
> a = b + c;
> 
> and b + c does not make sense but b and c are ranges for which a.front = 
> b.front + c.front does make sense, to automatically add the iteration 
> paraphernalia.
> 
> 3. It was mentioned in this group that if getopt() does not work in 
> SafeD, then SafeD may as well pack and go home. I agree. We need to make 
> it work. Three ideas discussed with Walter:
> 
> * Allow taking addresses of locals, but in that case switch allocation 
> from stack to heap, just like with delegates. If we only do that in 
> SafeD, behavior will be different than with regular D. In any case, it's 
> an inefficient proposition, particularly for getopt() which actually 
> does not need to escape the addresses - just fills them up.
> 
> * Allow @trusted (and maybe even @safe) functions to receive addresses 
> of locals. Statically check that they never escape an address of a 
> parameter. I think this is very interesting because it enlarges the 
> common ground of D and SafeD.
> 
> * Figure out a way to reconcile "ref" with variadics. This is the actual 
> reason why getopt chose to traffic in addresses, and fixing it is the 
> logical choice and my personal favorite.
> 
> 4. Allow private members inside a template using the eponymous trick:
> 
> template wyda(int x) {
>    private enum geeba = x / 2;
>    alias geeba wyda;
> }
> 
> The names inside an eponymous template are only accessible to the 
> current instantiation. For example, wyda!5 cannot access wyda!(4).geeba, 
> only its own geeba. That we we elegantly avoid the issue "where is this 
> symbol looked up?"
> 
> 5. Chain exceptions instead of having a recurrent exception terminate 
> the program. I'll dedicate a separate post to this.
> 
> 6. There must be many things I forgot to mention, or that cause grief to 
> many of us. Please add to/comment on this list.


7. opPow()

8. The magic "meta" namespace, aka. getting rid of is(typeof({...})) and 
__traits(...).


-Lars