On Tue, Oct 4, 2022 at 2:16 PM Barath Kannan via SG14 <sg14@lists.isocpp.org> 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. 

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.

There already are several solutions out there that offer most of these
For example
- my own https://github.com/psiha/functionoid (woefully in need of a cpp20 cleanup/rewrite) offers these through traits
- zoo function
- the new proxy thing from Microsoft https://devblogs.microsoft.com/cppblog/proxy-runtime-polymorphism-made-easier-than-ever which has a proposal paper accompanying it (and whose traits look strangely similar to mine :D)
...

WRT the main two (related) objections to standardizing something like this (something inherently less 'codegen-bloated and at the same time rigid' than std::function):
* vocabulary type/ABI problem
* 'ever new customization points'
...I don't find them convincing:
* the ABI thing can be sufficiently solved by
   - a function_ref thingie (for which most of the traits, such as sbo, moveability etc simply do not apply)
   - and the ability of the full on functionoid instantiations (for different, yet compatible, traits) to implicitly convert between one another (without capturing - i.e. w/o adding more indirect calls)
* 'traits expansion' - that would/should be built in from day-on - there are standard guaranteed traits and also vendor specific ones (like platform specific calling conventions) - and likewise new language version can add and/or deprecate/remove traits




--

Domagoj Šarić

Tech lead
C++ engineer

Microblink LTD
www.microblink.com