[Issue 3378] [tdpl] ++x should be an lvalue (page 2)

March 04, 2010
[Issue 3378] [tdpl] ++x should be an lvalue
Posted by Andrei Alexandrescu
in reply to Andrei Alexandrescu
Permalink
Andrei Alexandrescu
Posted in reply to Andrei Alexandrescu
Permalink
http://d.puremagic.com/issues/show_bug.cgi?id=3378



--- Comment #10 from Andrei Alexandrescu <andrei@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: -------
Forums
