On Friday, January 25, 2013 05:14:45 Era Scarecrow wrote: > On Friday, 25 January 2013 at 01:57:02 UTC, Jonathan M Davis > > wrote: > > 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. > > Personally that doesn't seem like it makes sense. I know it does > logically, but at the same time it seems silly. If you have > something as const, why do you need a non-const version?
With templated code, it can be important. But then again, if there's no point in having a non-const overload, you can simply not declare any overloads without const. You only run into problems when you mix const and non-const. The compiler has to be able to deal with various combinations of const and ref regardless of what it actually makes sense to declare. The only way that I can think of to get rid of that problem is to make it illegal to declare both const and non-const overloads at the same time, which seems unnecessarily restrictive (especially with regards to generic code), even if it doesn't normally make sense to overload on const. - Jonathan M Davis
