hof
hof copied to clipboard
The decorator created by the decorate adaptor should allow for constraints and multiple parameters
One way to do this is to have a second function passed to decorate, which will construct or pack the data. It can also be used to constrain the decorator.
Can you show an example of the need?
For example, the capture decorator can't be implemented using fit::decorate. However, adding the second parameter to decorate, capture could be implements like this:
auto capture = decorate([](auto&& p, auto&& f, auto&&... xs)
{
return pack_join(p, pack(xs...))(f);
}, pack);
And this could be useful when the user defines their own decorators, as well.
Another example is the log example. It requires a string parameter, however, if you pass it something that is not convertible to string, the error won't happen until the function is invoked:
std::vector<char> v;
auto logged_sum = log(v)(sum); // v is not valid, but there is no error here
auto x = logged_sum(1, 2); // Compile error here, even though the error should be in the first line
Using the second parameter, we can force it to always be a string:
auto log = decorate(log_f(), construct<std::string>());
auto logged_sum = log(v)(sum); // Compile error here because v is not convertible to string
I don't believe this is a good use case. It seems more than the decorate function either doesn't do enough or you want it to do too much things.
BTW, why we don't catch the error in line?
auto logged_sum = log(v)(sum); // v is not valid, but there is no error here
I don't believe this is a good use case. It seems more than the decorate function either doesn't do enough or you want it to do too much things.
I don't see it as too much, and it is a simple addition to fit::decorate to make it much more capable.
BTW, why we don't catch the error in line?
How could we? We can't know anything until we invoke the function.