On Tue, 4 Oct 2022 at 13:10, Barath Kannan <barathwaj.kannan_at_[hidden]>
wrote:

> Here are the list of customisation points I'd like on an erased function
> abstraction:
>
> - inplace buffer size, and exceed policy (concept failure vs defer to
> allocator), alignment
> - allocator
> - move only/copyable/non-relocatable
> - nullability, non nullables can assume the function object is set instead
> of checking and throwing (can kind of already achieve this with
> __builtin_unreachable)
> - trivially relocatable, so that the function object can be passed around
> by value
> - noexcept on constructor and call operator, and copy/move (latter can be
> made part of the signature)
> - owning vs non-owning (function ref vs other)
> - overload sets
>
> As long as there are differing requirements, people are going to want
> different sets of these so it'd be nice if we can just capture all of the
> above in a single abstraction via a policy set passed as a trait.
>

This would be a mess if every one of those dimensions was a policy on a
single class template. Owning vs non-owning completely changes the API and
should be separate types, look at the acrobatics needed for
std::function_ref to safely support non-owning without dangling.


>
> Would be nice if compatible policy sets also allowed implicit conversion
> (in the direction of relaxing requirements). E.g. trivial -> non trivial,
> conversion to object with larger SBO, copyable+moveable to move only, etc.
> Enabling this conversion may also be a trait people want to configure.
>

Yes, we'd all like ponies :-)

Unless you already have a proposal for all this, it seems like this list of
requirements will ensure nothing ever progresses past vapourware.