opStar

[Janice Caron]

On 11/10/07, Michel Fortin <michel.fortin at michelf.com> wrote:
> > Maybe Walter will add opStarAssign()?
>
> And then opStarAddAssign, opStarDivAssign, opStarShlAssign,
> opStarCatAssign...   no, that doesn't sound right.

Well you also can't do
    a[0] += n;
    a[0] /= n;
    a[0] <<= n;
    a[0] ~= n;

for classes overloading opIndex() and opIndexAssign().

No, I just see two big annoyances with opStar (three if you count the
fact that it's not called opDereference)

(1) You're forced to write (*a).b, and there's no convenient shortcut like a->b

(2) For a smart pointer to a struct, should *p return the entire
struct, or a pointer to it? If the latter, then the following two
lines would be completely equivalent:
    (**p).member;
    (*p).member;

which is slightly counterintuitive. And that's ignoring complexities
like what happens if a smart pointer points to a different kind of
smart pointer which points to something else.

In C++, the arrow operator is applied recursively until the compiler
finds a class that doesn't overload it, which is exactly what you
want.

That said, C++ provides both operator*() and operator->(), and they
can be overloaded independently, so if you're creating a smart
pointer, you have to overload operator->() to return a pointer
(because it's recursive), and then you have to overload operator*() to
return a reference (because it isn't).

So I guess I'm saying that

(1) The expression a.b should interpretted as follows. If a has a
member variable called b, then the expression is a reference to that;
if a has a member function opStar(), and the return type has a member
variable called b, then the expression is a reference to that; if both
are simultaneously true then it is an compile error.

(2) implicit in the above - operator overloads should be allowed to
return references, so they can be lvalues.

Then we can get rid of all the op*Assigns.