Short list with things to finish for D2

[Steven Schveighoffer]

On Wed, 18 Nov 2009 18:14:08 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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.

I don't like this.  The only useful thing I can see is if you wanted to  
write less code to do an operation on a wrapper aggregate, such as an  
array, where you could define all binary operations with a single mixin.

Other than that, it munges together all binary operations into a single  
function, when all those operations are different it:

1) prevents code separation from things that are considered separately
2) makes operators non-virtual, which can be solved by a thunk, but that  
seems like a lot of boilerplate code that will just cause bloat
3) If you derive from a class that implements an operator, and you want to  
make that operator virtual, it will be impossible
4) auto-generated documentation is going to *really* suck
5) you can't define operators on interfaces, or if you do, it looks  
ridiculous (a thunk function that dispatches to the virtual methods).
6) implementing a new operator in a derived class is virtually impossible  
(no pun intended).

I imagine that dcollections for example will be *very* hard to write with  
this change.

Seems like you are trying to solve a very focused problem without looking  
at the new problems your solution will cause outside that domain.

Can we do something like how opApply/ranges resolves? I.e. the compiler  
tries doing opAdd or opMul or whatever, and if that doesn't exist, try  
opBinary("+").

> 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.

Perhaps, but getopt is probably not the poster child for optimizing  
performance -- you most likely call it once, changing that single  
application to use heap data isn't going to make a difference.

> * 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.

I think allowing calling @trusted or @safe functions with addresses to  
locals is no good for @safe functions (i.e. a @safe function calls a  
@trusted function with an address to a local without heap-allocating).   
Remember the "returning a parameter array" problem...

> * 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.

This sounds like the best choice.

> 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.

I know it's not part of the spec, but I'm not sure if you mention the  
array "data stomping" problem in the book.  If not, the MRU cache needs to  
be implemented.

-Steve