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_at_[hidden]> 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!
>