--- Comment #14 from Witold Baryluk <> 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
> opIndexAssign.

Well only real problem with opIndexAssign is code duplication and return value
of opIndexAssign.
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[2] = a[3] =
5 will be then invalid, becuase (a[3] = 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
(@implicitIndexAssign ?)

> (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:
------- You are receiving this mail because: -------

Reply via email to