Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!netcom!sjsumcs!horstman
From: horstman@mathcs.sjsu.edu (Cay Horstmann)
Newsgroups: comp.lang.c++
Subject: Distinguishing lvalue/rvalue operator[]
Message-ID: <1991Mar3.202134.17812@mathcs.sjsu.edu>
Date: 3 Mar 91 20:21:34 GMT
Organization: San Jose State University - Math/CS Dept.
Lines: 35

I recently suggested to distinguish lvalue and rvalue operator[] by 
passing in an additional int for one of them, just like pre- and
post operator++ are distinguished in 2.1. Joe Buck suggested this is
unnecessary--one can have operator[] return an access class with 
     X& Access::operator=( X& ); // for lvalue usage
     Access::operator X(); // for rvalue usage
I just tried this out and it broke my code right away. The line
     a[i].print();
didn't compile--print() is not a member function of Access! Joe's suggestion
works fine for non-class types because the type conversion Access->X will
be executed, except before . and ->. Actually, I could surely come up
with a disgusting scenario where the overloading resolution rules give
unexpected results when one of the arguments of a function f with multiple
versions is f( ... a[i] ... ).

I repeat my call for two versions of this operator. William Miller had three
arguments against it.
(1) There is an alternate solution.
    I hope my argument against this is conclusive. 
(2) It breaks existing code
    Isn't it possible to map both lvalue and rvalue [] to the same 
    operator[](int) if an operator[](int,int) is not present?
(3) It makes operator[] special.
    I agree. On the other hand, it may well reasonable to have some operators
    special. The assignment operator= is clearly special. So is operator->.
    In fact, it probably makes sense to have both unary operator* and 
    operator[] lvalue/rvalue aware because their C analogs are. In contrast,
    operator++ shouldn't have this awareness because the C analog doesn't
    either. 
Two comments. The problem I encountered could be solved by overloading
operator. . <- the first is a dot operator, the second a sentence terminator.
I realize that the trick of supplying a second int argument isn't going to
work for distinguishing lvalue/rvalue occurrences of unary operator*. 

Cay