ARTICLE AD BOX
A possible future extension is to support multiple interfaces. For instance function_ref<void(int)> is only invocable with an int but perhaps a future function_ref<void(int), void(int, int)> 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<T> 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::lock_guard couldn't be made variadic and std::scoped_lock 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.
313k33 gold badges740 silver badges1.1k bronze badges
9 Comments
Do you foresee an ABI breaking issue if one were to propose relaxing the constraint on std::lock/std::try_lock (they require at least 2 Lockables today)? This restriction came up when I presented my proposal to add std::try_lock_for/std::try_lock_until (accepting 0-many TimedLockables) and someone (don't remember who) took it upon himself to write a proposal to relax the contraint on std::lock/std::try_lock.
2026-02-06T18:24:05.957Z+00:00
@TedLyngmo I don't see the requirement for at least 2 lockables here?
2026-02-06T19:21:15.743Z+00:00
template<class L1, class L2, class... L3> - there has to be an L1 and L2.
2026-02-06T19:38:21.473Z+00:00
@TedLyngmo LOL, clearly I did not read the declaration. Um, I don't know. I think it was MSVC that mangled things differently, so you'd have to check if void f(auto&, auto&...) and void f(auto&...) mangles the same for the same arguments?
2026-02-06T19:48:17.433Z+00:00
Function templates that are not explicitly instantiated are generally less concerning ABI-wise.
2026-02-06T19:54:42.153Z+00:00
This was added in revision 9 of the proposal. The changelog just says:
Declare the main template as variadic for future extension;
I didn't find any further explanation.
So this is intentional, but what kind of future extensions the authors have in mind isn't clear.
103k13 gold badges184 silver badges308 bronze badges
3 Comments
std::move_only_function's primary is also variadic. Perhaps there's a clue in that paper?
2026-02-06T14:59:55.44Z+00:00
@TedLyngmo Quickly skimmed through it, didn't find anything.
2026-02-06T17:41:43.077Z+00:00
Worth a shot! :-) It seems Barry knew the origin, so now we know at least.
2026-02-06T18:15:21.12Z+00:00
Explore related questions
See similar questions with these tags.
