I don't think that would work, considering that for practicality reasons, we need a std::function to hold onto the then callback to be able to invoke it when the future completes. Also, lambdas capturing unique_ptrs seem to be somewhat rare. Not sure that it is worth taking time to pursue a non-copying std::function alternative for non-copyable lambdas.
-- Janet Am Mo., 30. Aug. 2021 um 17:56 Uhr schrieb Ivan Čukić <ivan.cu...@kde.org>: > > > > `then` when calling it, which you lose if you switch from std::function to > > > a generic Fn parameter. But you can (since you're already using C++20) > > > restrict it with the std::invocable concept to avoid this loss of API > > > usage information. > > > > I still don't follow what this means for Croutons other than "don't > > use std::function because [jargon]". What exactly do I end up using > > instead...? > > Not really jargon, but maybe an overly technical explanation :) > > So instead of > > void then(std::function<ret(arg)> then_fn) > > you'd write (simplest alternative that uses static_assert to check > that the function object passed to .then has the correct signature) > > template <typename Fn> > void then(Fn then_fn) > { > static_assert(std::is_invocable_r_v<ret, Fn, arg>); > .... > } > > This is the solution that should fit the library the most. > > > If you want to overload .then for different types of function objects, > you can use concepts instead of static_assert. But it is a bit more involved. > > If you want to specify the argument type for the function object > and make the compiler allow only function objects that take a > value of type arg while ignoring the return type: > > template <std::invocable<arg> Fn> > void then(Fn then_fn) > { > .... > } > > > If you want to specify both the return type and the argument type > and have the compiler enforce both when the user calls .then: > > // Defines a concept similar to std::invocable, but allows to > // enforce the return type as well > template <typename Fn, typename Ret, typename Arg> > concept invocable_r = > requires(Fn fn) { > { std::invoke(fn, std::declval<Arg>()) } > -> std::convertible_to<Ret>; > }; > > template <invocable_r<ret, arg> Fn> > void then(Fn then_fn) > { > .... > } > > > > The point about move-only types doesn't seem to apply, considering all > > types in a future need to be understood by QVariant. > > The type in the future can be QVariant-able while the lambda you pass to > `then` might be move only because it uses a unique_ptr somewhere inside. > > Cheers, > Ivan > > -- > dr Ivan Čukić > i...@cukic.co, https://cukic.co/ > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12 > > >