[Issue 10574] "auto ref" fails to match when IFTI succeeds (strip to level const)

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Jul 11 11:17:32 PDT 2013


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



--- Comment #8 from monarchdodra at 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: -------


More information about the Digitalmars-d-bugs mailing list