Revised RFC on range design for D2

[Andrei Alexandrescu]

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.

Andrei