I have been told in a personal message that this would not replace the proposed (in the "games devs want" document) inplace_function as in that case, one could just use a bigger buffer size.

Yet, this (exposing the potential-allocation-ness as a conditional noexcept on the constructor) looks like something that could be achieved relatively quickly. What does the group think? Would it be a usability improvement for low-latency use-cases?

Le lun. 3 oct. 2022 à 17:23, Patrice Roy <patricer@gmail.com> a écrit :
Hi everyone!

In another thread, I mentioned the fact that many people in SG14 have stated that they would not use std::function since it might allocate. Jonathan Wakely (followed by a few others) suggested an interesting approach that I don't think we discussed previously:

What about making the constructor conditionally noexcept? The implementation knows whether a given type will be stored on the heap, and if that type can be constructed without throwing, so can easily expose that.

What people care about is a property of the constructor, so why not make it part of the constructor signature?

You can static assert is_nothrow_constructible.

If the SG14 contributors like this, we could turn it into a paper. It would (IMO) have a good chance of being accepted. This would let people use std::function without any risk of allocating in the cases where they care about this, and at essentially no cost. And if someone thinks all std::function cases in their codebase should be protected that way, they could envision writing a make_function() factory that would do this at no cost either, being essentially

template <class F> std::function<F> make_function(F && f) {
   static_assert(std::is_nothrow_constructible_v<std::function<F>>);
   return { std::forward<F>(f) };
}

What do you think?

Cheers!