On Thursday, January 24, 2013 17:13:36 Ali Çehreli wrote: > On 01/24/2013 12:25 PM, Era Scarecrow wrote: > >> What is also considered in function selection is the rvalue-lvalue > >> distinction, which shouldn't affect the outcome here either. > > > > In case David's explanation was too confusing, then let's look at it. If > > your variable is non-const, it will always select a non-const matching > > one first. If there is no matching non-const, it converts it to const, > > then tries again. > > > > void foo(A a) { > > writeln("without ref"); > > //a is an lvalue but not const > > //Foo(A) matches closer. Infinite loop > > And that's exactly why this issue is so confusing. > > Normally, const vs. immutable parameters are different in the way that > they accept arguments: > > - immutable is "limiting" because it insists that the argument is immutable. > > - const is "welcoming" because it accepts mutable, const, and immutable. > > However, according to your example and explanation above, in this case > const is not welcoming but limiting! What the example shows is that, > because the following function takes 'const ref A', now it "wants" > 'const A' but not 'A'. See, how in this case 'const' is not welcoming? > > That is the problem in this whole confusing situation. > > If there is another explanation that would bring sanity to the way I see > things, I would love to hear about it. Does my understanging above > regarding "limiting" vs. "welcoming" off? Perhaps that's where I go wrong?
I've never heard anyone describe it that way before. const is more generic, whereas immutable is more specific. But from the compiler's point of view, passing a non-const object to a const function means doing a conversion (from mutable to const), whereas calling a function of the same type does not require a conversion. I believe that _that_ is the core of why ref takes precedence over const. The overload rules avoid converting types as much as possible. So, if you have auto foo(A a) {...} //#1 auto foo(const A a) {...} //#2 A a; const A ca; foo(a); //calls #1 foo(ca); //calls #2 The same goes with ref. When passing an lvalue, the ref requires no conversion or copy, whereas without ref, a copy is required. So, auto foo(A a) {...} //#1 auto foo(ref A a) {...} //#2 A a; foo(a); //calls #2 foo(createA()); //calls #1 The question is what happens when you start mixing const and ref. You have to choose which has precedence. It's obvious what to do when you have all of the combinations auto foo(A a) {...} //#1 auto foo(ref A) {...} #2 auto foo(const A) {...} //#3 auto foo(ref const A) {...} //#4 A a; const A ca; foo(a); //Calls #2 foo(ca); //Calls #4 foo(createA()); //Calls #1 foo(createConstA()); //Calls #3 The problem is what to do when you only have a subset: auto foo(ref A) {...} #2 auto foo(const A) {...} //#3 A a; const A ca; foo(a); //Calls #2 foo(ca); //Calls #3 foo(createA()); //Calls #3 foo(createConstA()); //Calls #3 or auto foo(A a) {...} //#1 auto foo(ref const A) {...} //#4 A a; const A ca; foo(a); //Calls #4 foo(ca); //Calls #4 foo(createA()); //Calls #1 foo(createConstA()); //Calls #1 or etc... The compiler _has_ to pick either const or ref as having higher precedence. ref was almost certainly chosen as having higher precedence because it avoids a conversion, but also by picking ref, you end up with fewer unnecessary copies, making it the more efficient choice. So, from the standpoint of both type conversions and efficiency, it makes more sense for ref to have precedence over const than the other way around. The reality of the matter is that regardless of whether const or ref had precedence, you'd still need all 4 overloads or you'd have problems. auto ref and inout can help reduce the number of overloads required, but the function needs to accept all of the type combinations in order to avoid having to convert the type or make unnecessary copies. - Jonathan M Davis