Как это объясняется Вот, Значения разных категорий привязываются к ссылкам разных видов в соответствии со следующим порядком предпочтения:
struct s {};
void f ( s&); // #1
void f (const s&); // #2
void f ( s&&); // #3
void f (const s&&); // #4
const s g ();
s x;
const s cx;
f (s ()); // rvalue #3, #4, #2
f (g ()); // const rvalue #4, #2
f (x); // lvalue #1, #2
f (cx); // const lvalue #2
Где в стандарте описан этот порядок предпочтений?
[Over.ics.rank] / 3
— (3.1) Стандартная последовательность преобразованияS1
является лучшей последовательностью преобразования, чем стандартная последовательность преобразованияS2
если…
(3.1.3) —
S1
а такжеS2
являются ссылочными привязками (8.5.3), и ни одна из них не ссылается на неявный параметр объекта нестатической функции-члена, объявленной без квалификатора ref, иS1
связывает ссылку Rvalue с Rvalue иS2
связывает ссылку lvalue.…
(3.1.6) —
S1
а такжеS2
являются привязками ссылок (8.5.3), и типы, на которые ссылаются ссылки, относятся к одному и тому же типу, за исключением cv-квалификаторов верхнего уровня, и типа, к которому ссылка инициализируетсяS2
ссылка более квалифицирована по cv, чем тип, к которому ссылка инициализированаS1
относится.
Согласно этим правилам, функция, принимающая ссылку на rvalue, предпочтительнее, чем функция, принимающая ссылку на lvalue, а затем функция, принимающая неконстантную ссылку, предпочтительнее, чем функция, принимающая const. Разумеется, учитывая только жизнеспособные перегрузки.
Других решений пока нет …