Short list with things to finish for D2

[aarti_pl]

Andrei Alexandrescu pisze:
> 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.
> 
> 
> 
> Andrei

I kinda like this proposal. But I would rather call template like below:

T opInfix(string op)(T rhs) { ... }
T opPrefix(string op)(T rhs) { ... }
T opPostfix(string op)(T rhs) { ... }

and allow user to define her own operators (though it doesn't have to be 
done now).

I know that quite a few people here doesn't like to allow users to 
define their own operators, because it might obfuscate code. But it 
doesn't have to be like this. Someone here already mentioned here that 
it is not real problem for programs in C++. Good libraries don't abuse 
this functionality.

User defined operators would allow easy definition of Domain Specific 
Languages in D. I was already writing about it some time ago:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81026
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81352

BR
Marcin Kuszczak
(aarti_pl)