On Wed, 18 Nov 2009 18:14:08 -0500, Andrei Alexandrescu
<seewebsiteforem...@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
