http://d.puremagic.com/issues/show_bug.cgi?id=10574
--- Comment #8 from monarchdo...@gmail.com 2013-07-11 11:17:31 PDT --- (In reply to comment #7) > (In reply to comment #6) > > For the record (without putting any words in Kenji's mouth), I think he was > > just stating what the compiler was *doing*, and why the code was rejected. I > > don't think he meant to say that the current behavior was correct. > > > > Kenji, could you confirm that this is what you meant? That this is a correct > > "rejects-valid" ? > > No, indeed I just talked about the current compiler's work, but I'm sure that > current behavior is correct. > > The main point is what "auto ref" is doing - it's ref-ness deduction. > If given argument is an lvalue, auto ref parameter would become ref. If it's > an > rvalue, would become non-ref. Nothing else is done. > Type deduction and ref-ness deduction are completely orthogonal. It means that > the combination of each deduction results might finally reject given argument. > It's exactly what happened in the OP code. > > So I can say it's expected behavior. I strongly disagree. The argument of "ref-ness deduction" should be applied *after* type deduction. though. Applying it *before* makes no sense. Having a function that accepts an RValue of type U, yet reject an LValue of type U, is unheard of. It is strongly anti-expected. Finally, regardless of "how" auto ref works, this definitely goes against "what" auto ref is trying to solve: Writing functions that can take either by value or by ref, without having to write overloads. As is, the only solution here is to *not* use auto ref, but instead, write ref/value overloads: auto ref => Failed to provide solution it was designed for => design is flawed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------