Property rewriting; I feel it's important. Is there still time?

[Andrei Alexandrescu]

On 03/10/2010 09:14 PM, Chad J wrote:
> Andrei Alexandrescu wrote:
>> Well operator overloading handles indexing differently, and arguably
>> better than in your proposal. Ideally we'd define operators on
>> properties in a manner similar to the way indexing works in the new
>> operator overloading scheme. I'll talk to Walter about that.
>>
>>
>> Andrei
>
> I wouldn't want to have to define functions for side-effectful operators
> /in addition/ to the getter and setter.  The opIndexUnary/
> opIndexOpAssign things have bugged me a bit because I've felt that the
> value returned from opIndex should handle its own operator overloads.  I
> wonder if we are talking about two different things.

I hear you.

> The extra opIndexUnary/opIndexOpAssign overloads could supersede the
> behavior of getting from opIndex, mutating a temporary, and calling
> opIndexAssign with the temporary.  I'd still like to not /need/ to
> define the extra operator overloads though.

Yah, ideally both options should be available.

> Indexing seems to be the general case of properties: an indexed
> expression can be a getter/setter pair identified by both an identifier
> (the property's name: opIndex in this case) and some runtime variables
> (the indices).  The properties are a getter/setter pair identified by
> only the property's name alone.  This isn't much harder to deal with:
>
>      foo[i]++;
>
> ->
>
>      {auto t = foo.opIndex(i);
>       t++;
>       foo.opIndex(i,t) }()

I considered and rejected that design because it has a number of 
important practical drawbacks, such as unsuitability for certain 
containers (hashes, sparse vectors) and inefficiency.


Andrei