For better or for worse, the overload (2024)

Summary

You know what’s stuck on my mind? Ever since writing my last post, it’s been the word “better.” It came up when we were talking about overload resolution and implicit conversion sequences. I explained a necessary special case of it—something about how adding const in a reference-binding is preferred against—and then strategically shut up about the rest. void run(int (**f)()); // #1 void run(int (*const *f)() noexcept); // #2 int foo() noexcept; int (*p)() noexcept = &foo; run(&p); // ??? But it’s so tantalizing, isn’t it? Which one will it choose? How can we reason about this? I can see it in your eyes, sore but eager. You yearn for conversion. Well, I wasn’t going to— I— well… Alright, since you’re so insistent. Just for you. Shall we? ∗ ∗ ∗ Let’s start small and work our way up. An implicit conversion sequence is a standard conversion sequence, possibly followed by a user-defined conversion and another standard conversion sequence in the case of a class type. A user-defined conversion is something like T::operator S(), which defines how to convert a T into an S. These are easy: they work exactly how we tell them to. So, it evidently suffices to understand standard conversion sequences. Definition 1 A standard conversion sequence is a sequence of zero or one conversions from each of the following categories, in order: Lvalue-to-rvalue, array-to-pointer, or function-to-pointer conversions: Lvalue-to-rvalue: converts a glvalue of non-function, non-array type to a prvalue. Not particularly relevant to overload resolution, and kind of sophisticated, so we’ll mostly forget about this. Array-to-pointer: converts an expression of type “array of NNN T” or “array of unknown bound of T” to a prvalue of type “pointer to T,” applying temporary materialization conversion if the expression was a prvalue (note that GCC has a bug and won’t do this; temporary materialization is defined later). Function-to-pointer: converts an lvalue function of type T to a prvalue of type “pointer ...