On Sun, Oct 9, 2022 at 8:54 AM Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On 10/9/22 15:30, Arthur O'Dwyer via Std-Proposals wrote:
> On Sat, Oct 8, 2022 at 5:58 PM Jason McKesson wrote:
>     On Sat, Oct 8, 2022 at 5:46 PM Frederick Virchanza Gotham wrote:
>     >
>     > [...] left it as non-const though, because I didn't want someone
>     to be able to do
>     > the following:
>     >
>     >     short unsigned k = 7u;
>     >     Func(k);
>     >
>     > I didn't want the implicit conversion from rvalue to "reference to
>     const".
>
>
> FWIW, I think the status quo is fine (and you've now seen at least one,
> maybe two ways of dealing with the problem if you really need to). But
> as a data point / fun story, this came up in somebody (else)'s C++ Pub
> Quiz recently (maybe CppNorth? I forget the details), and was discussed
> briefly on the cpplang Slack.
> https://godbolt.org/z/c63hjo4xK <https://godbolt.org/z/c63hjo4xK>
>
> void f(int&&) { puts("int"); }
> void f(double&&) { puts("double"); }
>
> int main() {
> int i = 1;
> double d = 2;
> f(i); // prints "double"
> f(d); // prints "int"
> }
>
> Completely unsurprising, when you think about how this overload set
> needs to work:
> https://godbolt.org/z/4E7hsrqfz <https://godbolt.org/z/4E7hsrqfz>
>
> void f(const char *&) { puts("pointer"); }
> void f(std::string&&) { puts("string"); }
>
> int main() {
> const char *p = "hello";
> f(p); // prints "string"
> }

The last example prints "pointer".

Ha. In my defense, it's still before 9am here. :) I meant `const char*&&`:
https://godbolt.org/z/jKjP86bTa
 
The first example I'd call *anything but* unsurprising. Maybe for
language lawyers it is expected, but for most normal people it isn't.

That's how it ended up in a Pub Quiz!  But it's unsurprising when you think about how the overload set needs to work for strings, and then realize that C++ treats "implicit conversion to string" and "implicit conversion to float" essentially the same way. (Because C++ treats every type essentially the same way: you don't get different behavior in the first example just because the types involved in the first example happen to be "primitive" types.)

–Arthur