This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Volatile MEMs in statement expressions and functions inlined as trees


On 13-Dec-2001, Linus Torvalds <torvalds@transmeta.com> wrote:
> I stand by my argument.  Whether you _use_ the value of an assignment or
> not MUST NOT CHANGE THE SEMANTICS OF THE ASSIGNMENT.

Ah, Linus Torvalds, advocate of referential transparency ;-)


As a general rule, referential transparency -- having an expression
mean the same thing regardless of the context -- is usually a good thing.
If C++ didn't have so many side-effecting implicit conversions
and other violations of referential transparency, this might be
a stronger argument.

But the lvalue-to-rvalue conversion (4.1) is discussed right in a
section on implicit conversions (4) in a way that makes it clear that the
lval-to-rval-conv is itself an implicit conversion ("Standard conversions
are implicit conversions defined for built-in types. Clause 4 enumerates
the full set of such conversions.").  Like all implicit conversions,
whether or not it is invoked will depend on whether and how the lvalue
expression is used.

The language in 4.1 "An lvalue ... can be converted to an rvalue"
makes it clear that lvalues and rvalues are distinct.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]