smallfunction | Stack allocated and type-erased functors | Functional Programming library

The reporting from clang-tidy is definitely a bit weird and could use some clarification.

It's upset about the placement-new of Inner without seeing a matching explicit destructor call. You have this strange destroy() method that isn't even necessary since the Base destructor is virtual and the implicit Inner destructor will clean up Inner::f_.

This is trivially fixed in the following ways:

1. Replace bool SmallFunction::empty with Base *SmallFunction::value and store the result of the placement-new in it. (This is not strictly necessary, but I find the code flows better without requiring the reinterpret_cast, and it's easier to get right since the compiler can type-check.)
2. In SmallFunction::~SmallFunction, replace the destroy call with value->~Base().
3. Remove the destroy() method; it's not needed.

This satisfies clang-tidy (see here).

I don't think there was a memory leak, but there was an object (the Inner) that was constructed and never destructed. There is no consequence that I can see, but it doesn't hurt to do things the right way -- and it makes the job of static analyzers easier, anyway.