On Fri, 7 Oct 2022 at 16:57, Arthur O'Dwyer via SG14 <sg14_at_[hidden]>
wrote:

> On Tue, Oct 4, 2022 at 9:19 PM Patrice Roy via Lib <lib_at_[hidden]>
> wrote:
>
>> Le mar. 4 oct. 2022 à 17:47, Jonathan Wakely <cxx_at_[hidden]> a écrit :
>>
>>> On Tue, 4 Oct 2022 at 20:53, Barath Kannan <barathwaj.kannan_at_[hidden]>
>>> wrote:
>>>
>>>>
>>>> Which is why I'm inclined to agree with Arthur that people should just
>>>> write their own erasure abstractions (and if possible, the standard should
>>>> try to offer tools to make this easier) rather than standardising things
>>>> like inplace_function and any_invocable.
>>>>
>>>
>>> Agreed. std::function doesn't work well for everybody, but neither will
>>> whatever else we come up with. The standard library can't cover every use
>>> case.
>>>
>>
>> I understand that.
>> The SG14 requests we are discussing these days form a somehow coherent
>> whole, which I hope to turn into a somewhat coherent set of papers (not a
>> request for ponies, hopefully). It might take a couple of meetings for us
>> to decide the extent of this set of papers.
>> The aforementioned inplace_function<T,Sz> would be part of that [...]
>>
>
> I'd be interested to hear (perhaps off-list) whether anyone is actually
> using
> https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h
>
> https://github.com/Quuxplusone/SG14/blob/ajo/include/sg14/inplace_function.h
> as a third-party (or vendored) dependency in real life. The first
> criterion for "should it be in the standard" is always "are people already
> wanting to use it," and so far I haven't seen clear evidence (in the form
> of bug reports, feature requests, etc.) that anyone is actually using these
> things as they exist today.
>

Not exactly. Our non-allocating type-erasing function is trivial (and
requires the function object it contains to be trivial, obviously). The
thing is, if you allow type-erased move there's nothing stopping people
putting an unique_ptr (or indirect_value, if it needs to be copyable) in
there. Once you're paying for a vtable ptr, you may as well allow expanding
into allocated memory; it's basically zero extra cost.

That said, as the it's useful to know (and static_assert) that construction
won't allocate, but you can do that with a noexcept constrained ctor,
allowing the user to check is_nothrow_constructible or
noexcept(function(obj)). Or perhaps we could add a tagged (with
std::in_place_t, if that isn't too precious?) ctor or static factory method
to only accept non-allocating candidates.