Short list with things to finish for D2

dsimcha dsimcha at yahoo.com
Thu Nov 19 06:32:51 PST 2009


== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> 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("+").

This sounds like another candidate for inclusion in a std.mixins module.  We could
make a mixin that gives you back the old behavior for those cases were you need it:

enum string oldOperatorOverloading =
q{
    T opBinary(string op)(T rhs) {
        static if(op == "+"
            && __traits(compiles, this.opAdd(T.init)) {
            return opAdd(rhs);
        }
    }

    // etc.
};

Usage:

class Foo {
    mixin(oldOperatorOverloading);

    Foo opAdd(Foo rhs) {  /* do stuff. */ }
}



More information about the Digitalmars-d mailing list