Don 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 like the idea of enforcing relationships between operators. In fact, I
think we can take it even further, and require that operator overloading
in general *must* follow mathematical rules, and anything else leads to
undefined behaviour. For example, if n is an integer, a and b are
scalars, and x and y are general types, the compiler should be free to
rewrite
n*x <--> x + x + ... + x <--> 2*x + 2*x + ...
x^^n <--> x * x * ... * x <--> x^^2 * x^^2 * ...
x/a + y/b <--> (b*x + a*y)/(a*b)
and so on, based on what it finds to be the most efficient operations.
(Note how I snuck my favourite suggestion for an exponentiation operator
in there. I *really* want that.)
-Lars
