Rationale of variadicity of std::function_ref

A possible future extension is to support multiple interfaces. For instance functionref is only invocable with an int but perhaps a future functionref has two call operators, one that takes one int and one that takes two.

Whether we ever do this or not, making the primary template variadic makes such a future extension not an ABI break. On some platforms, C is mangled differently depending on whether C is a unary class template or a variadic class template, even though it still takes just the one type parameter. This was the reason that std::lockguard couldn't be made variadic and std::scopedlock was introduced in C++17.

Making it variadic now doesn't cost anything (just some raised eyebrows when you see the declaration), but is forwards-compatible with allowing multiple signatures in the future.