opStarAssign?

[Bill Baxter]

Janice Caron wrote:
> On 11/23/07, Leonard Dahlmann <leo.dahlmann at gmail.com> wrote:
>> What about *p *=, *p /=, *p ~=, ...?
>> Wouldn't these need overloads, too?
> 
> I don't see why. We've done just fine without a[n]*=, a[n]/=, a[n]~=
> and so on, so why should * be any different?
> 
> My preference would be to have the compiler rewrite
>     *p += n;
> 
> as
>     p.opDerefAssign(p.opDeref() + n);
> 
> (Ditto with .length, [] and so on). That way only two functions are
> needed, but you still get the full suite of expressability.
> 
> Note that if the compiler is able to inline both opDeref() and
> opDerefAssign() then you'd still get the efficiency of ... er ...
> opDerefAddAssign ... without having the clutter of a zillion different
> functions.
> 
> Of course, having functions return references is another approach too.

But the nice thing about the current approach is that it makes it easy 
to allow controlled or monitored access of your data.  If you return a 
reference you have no idea what they're going to do with it.

Of course you don't always care.  If you're providing a container class 
then returning a reference to the data element is exactly the behavior 
you want.  But if you don't want to expose your data in that way, then 
some automatic rewrite rules like you suggest would be nice.

I think both approaches have legitimate uses.  Implementing one does not 
eliminate the need for the other.

--bb