--- Comment #14 from Witold Baryluk <bary...@smp.if.uj.edu.pl> 2010-02-05
05:41:54 PST ---
(In reply to comment #11)
> (In reply to comment #4)
> > (In reply to comment #3)
> >> 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
> > All of these things are doable from a returned struct which contains
> > opAssign.
> But it would make code unnecessarily complex, and make the compiler have to
> work harder to optimise it to something as well-performing as a simple
Well only real problem with opIndexAssign is code duplication and return value
But this is easly solved:
- duplicated code can be easly moved to private auxilary method used both by
opIndex and opIndexAssign
- return value can be void if one doesn't want to use chaining (a = a =
5 will be then invalid, becuase (a = 5) have no value).
Other solution is to use opIndexAssign for assigment if it is implemented, then
try opIndex and check if it returns ref, if yes, perform opIndex + returned ref
dereferencing assigment, if both is not possible emit compile error.
If automatisation is not good, label opIndex by some kind of property
> (In reply to comment #10)
> > You are confusing opMul with opStar.
> Yet another reason opStar was the wrong choice of name, besides inconsistency.
Bad name indeed.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------