Xref: utzoo comp.lang.c++:11958 comp.std.c++:661
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: distinguishing operator[] on left and right
Message-ID: <1991Mar2.212017.13885@world.std.com>
Date: 2 Mar 91 21:20:17 GMT
References: <1991Feb28.212419.20920@ndl.com> <1991Mar2.000705.3496@mathcs.sjsu.edu>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 47

horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
> Just as pre- and postincrement operator++ are distinguished by a hidden
> int argument, could this not be done for lvalue and rvalue operator[]?
>
> I.e. const X& operator[]( int ) and X& operator[]( int, int )?
>
> The second int is always 0.
>
> If the second operator is not present, the first one is taken for both
> lvalues and rvalues.
>
> Points to consider:
>    (1) It is ugly as hell

No argument here. :-)  Seriously, I don't like the operator++() and
operator--() solution in E&S, either, although I don't know whether it's
worth fighting to change.

>    (2) It has precedent (operator++)
>    (3) It won't break existing code

Here's where I think the real problem with this proposal lies: it really
isn't parallel to the operator++() design.  The operator++() design *does*
break existing code -- if you don't provide the two-argument form, you can't
use postfix ++.  It would be YACC (Yet Another C++ Complexity :-) for
operator[]() to fold the cases but for operator++() not to do so.

The proposal also suffers from lack of generality: operator[]() is not the
only operator that can be used in lvalue and rvalue contexts.  Even if we
restrict ourselves to operators that can have lvalue results on builtin
types, there are (prefix) ++, (prefix) --, "," (comma), and all the
assignment operators (not to mention ?:, since it can't be overloaded); more
generally, all the overloaded operators can return a reference and hence be
used in lvalue contexts.  There's no compelling reason to believe that only
operator[]() would benefit from being able to distinguish between lvalue and
rvalue contexts.  For instance, how would you extend this to apply to prefix
operator++()?  There's already a meaning for operator++(int).

Another major consideration X3J16 applies to proposals is if there is a
straightforward way to achieve the desired results in the existing language.
As someone pointed out in an earlier posting, making operator[]() return an
object of an auxiliary class with separate operator=() and conversion
operator member functions is a pretty reasonable way to address this problem
where it's needed, and it's more generally applicable, as well.

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com