On Sat, Aug 15, 2026 at 8:32 AM ycjin_kim via SG14 <sg14_at_[hidden]>
wrote:

> My name is Kim, a developer interested in embedded systems. I'd like to
> share a project I've been working on called "Embedded Function" and get the
> group's feedback.
>
> `Embedded Function` is a lightweight, header-only library that provides a
> collection of heap-free polymorphic function wrappers (like `ebd::fn`,
> `ebd::unique_fn`, `ebd::fn_ref`). [...]
> While the `stdext::inplace_function` implementation exists in the SG14
> repository, it seems the standardization effort has not progressed
> recently. My library aims to be a modern, production-ready alternative. It
> offers several variants (`fn`, `unique_fn`, `classic_fn`, `fn_ref`) to
> cover different use cases, similar to what `std::function`,
> `std::copyable_function`, and `std::function_ref` provide.
>

Such a thing is useful, but personally I don't think it deserves to be put
into the Standard Library. There are just too many "design knobs"
<https://quuxplusone.github.io/blog/2019/03/27/design-space-for-std-function/>
to please everyone; and the STL is constrained by historical decisions.
E.g. two of my pet peeves about `std::function`—
(1) You can store `int(*)()` into `function<void()>` with no diagnostic at
all. In my experience, this conversion is almost invariably a bug, and
we've found bugs by replacing `std::function` with our own version that
lacks this "lossy" conversion.
(2) `function<bool()>` is contextually convertible to `bool`, such that `if
(f)` means something different from `if (f())`. This is perfectly
consistent with other types (e.g. `int`, e.g. `bool(*)()`) but again
usually indicates a bug, and we've found bugs by replacing `std::function`
with our own version that lacks this boolean conversion. Likewise
assignment from, and comparison to, `nullptr`.

A new `function`-alike in the STL probably *can't* fix these issues;
certainly `copyable_function` and `unique_function` *did not* fix them. At
the very least, standardizing this kind of thing would mean arguing over
each design decision, and ultimately putting each decision to a vote, which
would produce the wrong answer for about half the decisions.
But *a new third-party library* could get these decisions "right" for its
own users, and show other programmers the way to implement their own types
that will be "right" for *them*.

That's basically what `sg14::inplace_function
<https://github.com/Quuxplusone/SG14#in-place-type-erased-types-future--c14>`
is trying to do: get most decisions right and/or consistent with the STL,
and provide a reference implementation for others to copy.
(Btw, note that I forked WG21-SG14/SG14 into Quuxplusone/SG14 quite a while
ago now. I'm not aware that *anyone* is maintaining WG21-SG14/SG14 anymore;
nor is anything in it being actively proposed by anyone at the moment.)

- Are there any features or design choices you think are missing or could
> be improved?
>

I didn't look closely, but just from looking at the API docs...
Your `fn<Sig, Cap>` seems to be missing an `Alignment` parameter. This
means that there are callable objects it can't safely hold:
  struct alignas(128) F { int i_; void operator()() const; };
  fn<void() const, sizeof(F)> f = F(); // does this compile? Hard to tell;
hopefully it compiles or not depending on the "implementation-defined"
alignof(f)
  fn<void() const, sizeof(F), alignof(F)> f = F(); // This would be a
"safer" interface

Cheers,
Arthur