Le mar. 4 oct. 2022 à 17:47, Jonathan Wakely <
cxx@kayari.org> a écrit :
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
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.