Croutons in kdereview

[Ivan Čukić]

> > `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