Why is this overload of a conversion operator chosen?

Question

struct any
{
    template <typename T>
    operator T &&() const;

    template <typename T>
    operator T &() const;
};
int main()
{
    int a = any{};
}

Here the second conversion operator is chosen by the overload resolution. Why?

As far as I understand it, the two operators are deduced to operator int &&() const and operator int &() const respectively. Both are in the set of viable functions. Reading through [over.match.best] didn't help me figure out why the latter is better.

Why is the latter function better than the former?

I'm a simple cat and I'd say it must be the second once else the introduction of the other would have been a breaking change in C++11. It'll be in the standard somewhere. Good question though, have an upvote. (Attention experts: if this comment is hogwash then please tell me!) — Bathsheba, Dec 02 '19 at 16:02
FWIW, `template operator T &&() const &&; template operator T &() const &;` gets it to call the first one. — NathanOliver, Dec 02 '19 at 16:03
@LightnessRaceswithMonica Conversion operators allow it otherwise there would be no way to have multiple conversion operators. — NathanOliver, Dec 02 '19 at 16:07
@Bathsheba I don't think that's the reason why. That's like saying that move constructors can never be selected by overload resolution because it would be a breaking change. If you write a move constructor, you are opting in to your code being "broken" by that definition. — Brian Bi, Dec 02 '19 at 16:07
@Brian: That's a good point: `any{};` syntax was new to C++11 too. — Bathsheba, Dec 02 '19 at 16:08
@LightnessRaceswithMonica The way I keep it straight in my head is I treat the return type as the name of the function. Different types equals different names equals success :) — NathanOliver, Dec 02 '19 at 16:11
@NathanOliver-ReinstateMonica: That’s not just you: that [**is** the function’s name](http://eel.is/c++draft/class.conv.fct#1). Which means that `operator T` is a dependent name, which is fun… — Davis Herring, Dec 02 '19 at 21:06
@NathanOliver-ReinstateMonica "_treat the return type as the name of the function_" Because an implicit conversion must be activated implicitly, it obviously couldn't follow any usual C++ function name rule! They had to make ad hoc declaration syntax and ad hoc overloading rules. C++ can be criticized for its many special cases that make the language too complex, many of which are useless or the unavoidable effect for other design issues, but this special case is useful. — curiousguy, Dec 03 '19 at 13:28

score 13 · Accepted Answer · answered Dec 02 '19 at 16:19

The conversion operator that returns T& is preferred because it is more specialized than the conversion operator that returns T&&.

See C++17 [temp.deduct.partial]/(3.2):

In the context of a call to a conversion function, the return types of the conversion function templates are used.

and /9:

If, for a given type, deduction succeeds in both directions (i.e., the types are identical after the transformations above) and both P and A were reference types (before being replaced with the type referred to above): — if the type from the argument template was an lvalue reference and the type from the parameter template was not, the parameter type is not considered to be at least as specialized as the argument type; ...

Yakk - Adam Nevraumont · Answer 2 · 2019-12-02T18:08:48.500

The deduced return value conversion operators are a bit strange. But the core idea is that it acts like a function parameter to pick which one is used.

And when deciding between T&& and T& the T& wins in the overload resolution rules. This is to permit:

template<class T>
void f( T&& ) { std::cout << "rvalue"; }
template<class T>
void f( T& ) { std::cout << "lvalue"; }

to work. T&& can match against an lvalue, but when both the lvalue and universal reference overloads are available, the lvalue one is preferred.

The right set of conversion operators is probably:

template <typename T>
operator T&&() &&;

template <typename T>
operator T &() const; // maybe &

or even

template <typename T>
operator T() &&;

template <typename T>
operator T &() const; // maybe &

to prevent failed lifetime extension from biting you.

3 The types used to determine the ordering depend on the context in which the partial ordering is done:

[SNIP]

(3.2) In the context of a call to a conversion function, the return types of the conversion function templates are used.

Which then ends up depending on "more specialized" rules when picking overloads:

(9.1) if the type from the argument template was an lvalue reference and the type from the parameter template was not, the parameter type is not considered to be at least as specialized as the argument type; otherwise,

Thus operator T&& is not at least as specialized as operator T&, meanwhile no rule states operator T& is not at least as specialized as operator T&&, so operator T& is more specialized than operator T&&.

More specialized templates win overload resolution over less, everything else being equal.

Someone added the [tag:language-lawyer] tag as I was answering; I could simply delete. I have a vague memory of reading the text that states that it is treated as a parameter to pick which one is called, and the text that talks about how `&&` vs `&` is treated when picking template overloads, but teasing out the exact text would take a while. — Yakk - Adam Nevraumont, Dec 02 '19 at 16:14

score 4 · Answer 3 · edited Jun 20 '20 at 09:12

We're trying to initialize an int from an any. The process for that it:

Figure out all the way we can do that. That is, determine all of our candidates. These come from the non-explicit conversion functions that can be converted to int via a standard conversion sequence ([over.match.conv]). The section contains this phrase:

A call to a conversion function returning “reference to X” is a glvalue of type X, and such a conversion function is therefore considered to yield X for this process of selecting candidate functions.
Pick the best candidate.

After step 1, we have two candidates. operator int&() const and operator int&&() const, both of which are considered to yield int for the purposes of selecting candidate functions. Which is the best candidate yielding int?

We do have a tiebreaker that prefers lvalue references to rvalue references ([over.ics.rank]/3.2.3). We're not really binding a reference here though, and the example there is somewhat inverted - this is for the case where the parameter is an lvalue vs rvalue reference.

If that doesn't apply, then we fall through to the [over.match.best]/2.5 tiebreaker of preferring the more specialized function template.

Generally speaking, the rule of thumb is the more specific conversion is the best match. The lvalue reference conversion function is more specific than the forwarding reference conversion function, so it's preferred. There's nothing about the int we're initializing that requires an rvalue (had we instead been initializing an int&&, then the operator T&() const would not have been a candidate).

3.2.3 actually says `T&&` wins doesn't it? Ah, but we don't have an rvalue being bound to. Or do we? When picking our candidates some words must have defined how we got `int&` and `int&&`, was that a binding? — Yakk - Adam Nevraumont, Dec 02 '19 at 16:43
@Yakk-AdamNevraumont No, that one prefers lvalue references to rvalue references. I think that's probably the wrong section anyway, and the "more specialized" tiebreaker is the correct one. — Barry, Dec 02 '19 at 16:53

Why is this overload of a conversion operator chosen?

3 Answers3