Revised RFC on range design for D2

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Sergey Gromov wrote:
>> Fri, 3 Oct 2008 09:37:46 +0900,
>> Bill Baxter wrote:
>>> On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter at gmail.com> wrote:
>>>> On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly at gmail.com> 
>>>> wrote:
>>>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>>>> Andrei Alexandrescu wrote:
>>>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
>>>>>> ask...
>>>>>> any ideas? :o)
>>>>>>
>>>>>> One goal is to fix opIndexAssign and make it work similar to the way 
>>>>>> it
>>>>>> works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
>>>>>> test bed.
>>>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>>>>
>>>> Indeed.  I thought there wasn't a lot of debate needed on this, just 
>>>> action.
>>> .
>>> ... except these extras do have the same issue that plain property
>>> assignment does.  They would open up a new class of things that are
>>> valid code but don't behave as expected.  writefln += 5.
>>>
>>> And also, a[b] += c should probably be rewritten as  "a.opIndex(b) +=
>>> c"  *if* a returns a reference of some sort.  Ok, so maybe there is a
>>> little to talk about.  :-)
>>
>> I think that any expression "a @= b" should first check whether the 
>> expression on the left is an lvalue.  If yes then use it as any other 
>> lvalue, otherwise try to re-write an expression using op at Assign.  This 
>> works in many scenarios, like opIndex returning a reference.
>
> That's a good rule, but a[b] @= c on a hash is not helped by it.

I think Sergey didn't write his rules correctly.  If a is an lvalue, use it 
as any other lvalue, which *includes* trying op at Assign.

If a is not an lvalue, then rewrite the expression as a = a @b, without 
expanding operators, then use normal operator expansion to compile the 
statement.

If neither works, then it is a syntax error.

This should be valid for all cases.  For example a hash that returns a 
reference for opIndex:

a[b] += c;

a.opIndex(b) is an lvalue, so try: a.opIndex(b).opAddAssign(c).  If that 
doesn't work, then syntax error.

case 2, a[b] is an rvalue:

rewrite as a[b] = a[b] + c;

expand operators:

a.opIndexAssign(a[b] + c, b);
a.opIndexAssign(a.opIndex(b) + c, b);

An example of a failure:

int foo(int x) {...}

foo(5) += 6;

left side is an rvalue, so try rewriting:

foo(5) = foo(5) + 6;

syntax error, foo(5) is still an rvalue

Any cases that break with these rules?

-Steve