[Issue 3378] [tdpl] ++x should be an lvalue

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3378



--- Comment #10 from Andrei Alexandrescu <andrei at metalanguage.com> 2010-03-04 08:03:40 PST ---
(In reply to comment #9)
> (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
> lvalue.
> 
> > 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.

There's no need to get worried about this, particularly on Walter's behalf
(e.g. the cost of implementing the change etc.). We're already past the point
where debate is pointless. If there were any advantage in making things an
rvalue, keeping TDPL as it is would never be an issue so there's no need to
worry about making shady compromises either. Please no generalizations. Clearly
this is a minor issue, and clearly there is a marginal gain for making the
blessed thing an lvalue. So let's make it an lvalue and worry about larger
issues.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------