--- Comment #3 from Stewart Gordon <s...@iname.com> 2009-07-17 12:35:45 PDT ---
(In reply to comment #2)
>> Given that opIndexAssign doesn't occur in your code, removing
>> opIndexAssign from the language isn't going to magically make this
> I don't see why not. "a[1, 1] = 42;" should just become
> "a.opIndex(1, 1) = 42;" rather than do something special because
> the "=" is there.
Welcome to D. The expansion of a given expression form is by no means fixed.
Already an example of this is that many operators can be overloaded either by
the left operand's type (using the regular op* methods) or the right operand's
type (using the op*_r methods). In the same way, the existence of
opIndexAssign does nothing whatsoever to prevent the compiler from expanding it
to something else instead if the type in question has no opIndexAssign. And
even then, that something else would have to be implemented, which is another
piece of work.
> I am under the impression that opIndexAssign is there only because
> return by reference was not available at the time of designing
> operator overloads.
That's one reason. The other reason is that it can do many things that a ref
return can't, such as
- converting the value to an internal representation
- validating the set value
- calling some external API to set the value
- triggering side effects beyond setting the value in memory
It's the exact same reason that we have properties.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------