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





--- Comment #10 from Steven Schveighoffer <schveiguy@yahoo.com>  2009-07-27 08:20:13 PDT ---
(In reply to comment #7)
> opMulAssign exists and return by ref was meant to solve an unrelated problem, I believe. It's not a replacement for assign operators.

You are confusing opMul with opStar.

opStarAssign would be for dereferencing.  For example:

*ptr = 5;

And currently it's not necessary, since the return value from opStar is a reference.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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





--- Comment #11 from Stewart Gordon <smjg@iname.com>  2009-07-27 09:22:16 PDT ---
(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.

(In reply to comment #10)
> You are confusing opMul with opStar.

Yet another reason opStar was the wrong choice of name, besides inconsistency.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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





--- Comment #12 from Sobirari Muhomori <maxmo@pochta.ru>  2009-07-28 02:27:44 PDT ---
opStarAssign sounds just like *= so I though it is it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #13 from Witold Baryluk <baryluk@smp.if.uj.edu.pl> 2010-02-05 05:36:12 PST ---
I again want to say that returning ref is no possible in case of my ussages opIndexAssign.

For example I would like to log assigments. Or keep internal caching system.
Also it is possible that i have datastructure which needs to know size of the
object (string) which i put there, to allocate and rebalance this
datastructure.
When i would return ref, it would not be possible to perform any such thinkg.


Leave opIndexAssign it is very usefull.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #14 from Witold Baryluk <baryluk@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: -------

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


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andrei@metalanguage.com
         Resolution|                            |FIXED


--- Comment #15 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-01-08 22:03:26 PST ---
Fixed in the new design.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------