On Sunday, 30 June 2013 at 09:46:00 UTC, Maxim Fomin wrote:
In the 9498 issue there is a discussion about such code:
string[string] myValues;
ref string getValue(string v) {
return myValues[v];
}
void main() {
getValue("myValue") = "myString";
}
Currently it throws range violation as myValues[v] is regarged
as rvalue (in Andrei's notion it is a read operation).
On the one hand, returning some value from AA array is a read
operation which should throw as it happens with non-ref
function. It is also impossible to know whether some new value
would be assigned or just be copied like this:
string s = getValue(); // obviously read operation which need
throw.
tl;dr it does not really matter how value is returned, only
whether is exists or not.
On the other hand, as original code shows, it could be write
operation, so function should not throw.
Spec is silent about this and TDPL barely discusses it, let
alone ref corner case.
Thoughts?
http://d.puremagic.com/issues/show_bug.cgi?id=9498
As you said, associative arrays are accessed through read or
write operations, they do not return by ref. This is done using a
simple rewrite rule replacing assignment with a call to the
setter, and it is the container (the associative array) which
implements "opSliceAssign" operation, so it is only when
accessing that container that the rewrite should occur.
If assignment of the return type is wanted, it can be achieved by
returning a type which implements "opAssign" which then does the
write operation.
