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
