1<!-- Copyright 2018 Paul Fultz II 2 Distributed under the Boost Software License, Version 1.0. 3 (http://www.boost.org/LICENSE_1_0.txt) 4--> 5 6Partial function evaluation 7=========================== 8 9Many of the adaptors(such as [partial](partial) or [pipable](pipable)) in the library supports optional partial evaluation of functions. For example, if we have the `sum` function adapted with the `partial` adaptor: 10 11 auto sum = partial([](int x, int y) 12 { 13 return x+y; 14 }); 15 16So if we write `sum(1, 2)` it will return 3, however, if we write `sum(1)` it will return a new function, which when called again, it will evaluate the function and return 3: 17 18 int i = sum(1, 2); // Returns 3 19 auto f = sum(1); 20 int j = f(2); // returns 3 21 22Of course due to limitations in C++, deciding whether evaluate the function or to partially evaluated it, is based on the callability of the function and not arity. So if we call `sum(1, 2, 3)`, it will return a function: 23 24 auto f = sum(1, 2, 3); 25 26However, this can get out of hande as the function `f` will never be evaluated. Plus, it would be nice to produce an error at the point of calling the function rather than a confusing error of trying to use a partial function. The [limit](limit) decorator lets us annotate the function with the max arity: 27 28 auto sum = partial(limit_c<2>([](int x, int y) 29 { 30 return x+y; 31 })); 32 33So now if we call `sum(1, 2, 3)`, we will get a compiler error. So this improves the situation, but it is not without its limitations. For example if we were to define a triple sum using the [pipable](pipable) adaptor: 34 35 auto sum = pipable(limit_c<3>([](int x, int y, int z) 36 { 37 return x+y+z; 38 })); 39 40So if we call `sum(1)`, there is no compiler error, not until we try to pipe in a value: 41 42 auto f = sum(1); // No error here 43 auto i = 2 | f; // Compile error 44 45Of course, the goal may not be to use the pipable call, which could lead to some confusing errors. Currently, there is not a good solution to this. 46 47