http://d.puremagic.com/issues/show_bug.cgi?id=3378
--- Comment #9 from Steven Schveighoffer <[email protected]> 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 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
