On Tue, Oct 4, 2022 at 2:16 PM Barath Kannan via SG14 <sg14_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.
>
> 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 <https://microblink.com/>
<https://microblink.com/>