[Issue 3188] remove opIndexAssign from the language

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3188



--- Comment #14 from Witold Baryluk <baryluk at 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
> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------