🚀 go-pugleaf

In article <1991Apr25.030006.5849@csi.uottawa.ca> hitz@sim5.csi.uottawa.ca (Martin Hitz) writes:
>In article <1991Apr24.184018.23427@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>>In article <950@edg1.UUCP> jsa@edg1.UUCP (J. Stephen Adamczyk) writes:
>>>The ARM (5.1.7) says that the value of an assignment operator is
>>>an lvalue.  That's different than ANSI C (3.3.16).  There must
>>>be a reason for the difference; can anyone enlighten me?
>>
>>I surmise, without really knowing, that people want to write things
>>like `(a = b).foo', for which it is required that the assignment
>>return an lvalue.
>
>No. Consider the following program:
> [deleted]
>
>f() does NOT return an lvalue, the last line in the program is therefore
>illegal. However, f().i is of course allowed, and so would be (a = b).foo, 
>even if = didn't return an lvalue.

Oops, I meant to say `(a = b).foo()'.  As I read E&S, this would still
be legal if assignment returned an rvalue, but would mean something
different: where the current meaning is the same as `(a = b, a.foo())' ,
if assignment returned an rvalue, it would be more like

    T temp = (a = b);
    temp.foo();

However, I can't completely convince myself that this analysis is
correct, because while E&S (5.17, p. 79) says that the result of an
assignment is an lvalue, it neglects to say *which* lvalue it is.
This seems like a lacuna in the specification.

-- Scott
Gyro@Reasoning.COM