Croutons in kdereview
Ivan Čukić
ivan.cukic at kde.org
Mon Aug 30 22:56:36 BST 2021
> > `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ć
ivan at cukic.co, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
More information about the kde-core-devel
mailing list