http://d.puremagic.com/issues/show_bug.cgi?id=3188
--- 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 > 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: -------