On Tue, 13 Oct 2009 11:56:36 -0400, Don <nos...@nospam.com> wrote:
Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurred to me: we could simply use overloading
with the existing operator names. Consider:
a += b
gets rewritten as
a.opAddAssign(b)
Then how about this - rewrite this:
a[b] += c
as
a.opAddAssign(b, c);
There's no chance of ambiguity because the parameter counts are
different. Moreover, this scales to multiple indexes:
a[b1, b2, ..., bn] = c
gets rewritten as
a.opAddAssign(b1, b2, ..., bn, c)
What do you think? I may be missing some important cases or threats.
Andrei
Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.
The indexing thing was something I didn't have a solution for.
BTW we need to deal with slices as well as indexes. I think the way to
do this is to make a slice into a type of index.
I've mentioned this problem before, in relation to multi-dimensional
arrays:
// Slice a row out of an Matrix
row0 = myMatrix[0,0..$];
So basically, opIndex and opSlice need to merge to support this use case.
I've always ended up doing this with using size_t[2] or size_t[3] (for
slicing with strides) when I've coded Nd-arrays, though this is a bit
clunky. However, a while ago someone mentioned that tuple, though
cool/useful/etc wasn't being used as much (compared to other languages)
because of a lack of syntactic sugar. Which gave me the idea of using the
.. operator to be syntactic sugar for tuple, as it would solve two birds
with one stone. (Maybe three, if you count MVR)
Also needed is an extension of the opDollar to return different values
based on the index:
opDollar(size_t index);
P.S. There's also at least one template bug blocking Nd-arrays and small
vector types: (http://d.puremagic.com/issues/show_bug.cgi?id=2257).
P.S.S. Another template issue is that templating both opX and opX_r
generally results in an overload conflict.
