--- Comment #9 from Steven Schveighoffer <> 2010-03-04 
06:09:51 PST ---
(In reply to comment #8)
> I can't rewrite bump because it's part of a large example illustrating ref. 

I don't wish to have a largeish debate about this, but this is not a good
reason.  My rewritten version illustrates ref just as well.  The only
difference between mine and yours is that yours illustrates that ++x is an

> The
> book is in copyediting now and I must limit changes as much as possible. All
> other things equal, lvalue is better because there's less rewrite needed.

Less rewrite of the book, more rewrite of the compiler.  It's a shame we have
to make a decision based on this.  That being said, you stated before there
would be more changes needed in the book.  Can we get an idea of how much of a
rewrite we are talking about?

> One extra point to keep in mind: making ++x an lvalue makes compatible
> implementations for UDTs' ++ cheaper.

Making ++x an lvalue would still be possible with UDTs, you can return whatever
you wish from a custom operator.  Even if ++x is an lvalue for builtins it
still will be possible to make ++x an rvalue for UDTs.  Returning an lvalue
from a UDT is most likely not because it should be used as an lvalue, but more
likely because returning an lvalue performs better.  This consideration has
little or no bearing on ++x for builtins.  In other words, the fact that UDTs
return an lvalue is a side effect that maybe shouldn't really be exploited in
generic code.

Superficially, all operators that return classes return lvalues, i.e. for a
class A that returns an A on addition and supports assignment from an int will
support something like:

a + a = 5;

which doesn't make any sense for value types, but should we make addition of
two integers return an lvalue for the sake of generic programming so such
statements always compile?  I think we should stop debating about the generic
term ++x being an lvalue and focus on whether ++x should be an lvalue for
builtin types, simply because the compiler does not control the lvalueness of
++x for UDTs.  When you look at it that way, it's simply a judgement call.

I'm not saying I'm against changing the behavior, it just seems like an
insignificant change to me.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to