why std::move_only_function and std::copyable_function

[willow rampart]

Why are they needed std::function seems copyable and movable. tbh is not move only but elighten what are their specific issues

[granite meadow]

When your question is answered use !solved or the button below to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[regal parcel]

std::function can only accept functions that are themselves copyable. If yours is move-only, you're out of luck

std::move_only_function can accept those, but is itself not copyable

std::copyable_function is basically std::function 2.0

[willow rampart]

why is that

[regal parcel]

You mean why rewrite std::function?

[willow rampart]

can you give an example of a move-only function? i assume it has to be a lambda or functor of some form or shape

[willow rampart]

yes

[regal parcel]

Yeah. E.g. a lambda that captures a std::unique_ptr

[willow rampart]

ah ok that makes sense i hadn't thought about lambda with unique ptr

[regal parcel]

If you're asking about std::copyable_function, then apparently they made it to fix some issues that std::function had. At least one of them is that it's not const-correct, i.e. its operator() is const, but it can call a non-const () on the underlying function

std::move_only_function also had this fix, so it makes sense to have them consistent

[willow rampart]

and they made another one instead of fixing std::function because ABI blah blah ?

[regal parcel]

Not even ABI, it breaks API too

The const correctness thing affects API

[willow rampart]

i dont see the issue with the API i mean things change from one c++ standar to the other why cant it break the API as long as ABI is fine

or maybe i dont fully understand the effects of it

[regal parcel]

I'm not sure ABI is the same either 😛

But even regarding API, C++ tries to stay compatible with previous revisions