Hi,
here it is my review.
I believe that Boost.Fit should be*accepted*.
Thanks for the review.
*Design*
The design is sound and clean.
I have some concerns respect the the ConstFunctionObjects that I believe should merit an explanation on a rationale section. Why the library support only Const function objects?
This is described in the FAQ, but maybe it should be moved to a rationale section. The main reasons are they are error prone, and in C++11 can’t be supported with constexpr.
Wondering if some parts should be moved to Boost.TypeTraits or reused from there (is_callable).
But would that imply a C++98 compatible trait? Of course, I don’t see a reason to dump every trait used in boost into Boost.TypeTraits.
I'm missing the std::invoke function.
What do you mean? std::invoke is provided by C++17. There is fit::apply, which will work like std::invoke except fit::apply also uses constexpr and is defined as a function object(so it can be passed to other functions).
The_adaptor<> are not documented.
Maybe in the definitions section I can go over how `foo(f)` is the same as `foo_adaptor<F>{f}`.
The utility of those classes is not documented.
The are mainly useful for when you want to type-based transformations to functions. This is common when you need to pass a function as a template parameter(like with the comparator in std::map, the deleter in std::unique_ptr, or when using Boost.MultiIndex).
If the user can use those classes the documentaion must document them. I guess they are useful to build other adaptors. It is not clear whether the defined functions would use SFINAE or just fail when used with types that don't respect the requirements. While I'm generally for SFINAE, I understand that it will not be the case in order to improve the compile time.
The goal is to be as transparent as possible. So if `foo(f)(x)` is equivalent to `f(x)`, then if `f(x)` causes substitution failure, then `foo(f)(x)` causes substitution failure. The same is true for constexpr and noexcept on compilers that support those well enough.
It is not clear if the functions can be final function objects or not.
They can be. There is no such restriction mentioned for the `Callable` or `ConstCallable` concept.
*Implementation*
Not seen in depth.
It should use as much as possible Boost.Config and/or Boost.Predef
Right now it uses sd-6 macros, but it could move to use Boost.Config(probably not Boost.Predef).
Well hana uses a static_cast. Here, I use a macro which uses a static_cast if possible, and then I fallback to a function on compilers that can’t handle the static_cast.
Well, I dont know of a library in boost that implements the fast_and algorithm that works on gcc 4.6+ and msvc.
I dont know of a library that implements this. There is Boost.CompressedPair, but that implementation wouldn’t work at all for the Fit library.
This probably could be factored out in a separate boost library, which might be useful for other heavy metaprogramming libraries.
https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/pp.hpphttps://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/remove_rvalue_reference.hpp
https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/result_of.hpp
https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/static_const_var.hpp
https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/using.hpp
It uses a lot of macros that make complex the understanding of what is behind. On the same file https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/compose.hpp and only on 169 lines
BOOST_FIT_INHERIT_CONSTRUCTOR, BOOST_FIT_RETURNS_CLASS,
BOOST_FIT_SFINAE_RESULT, BOOST_FIT_MANGLE_CAST, BOOST_FIT_DECLARE_STATIC_VAR, BOOST_FIT_NOEXCEPT_CONSTRUCTIBLE,
BOOST_FIT_ENABLE_IF_CONSTRUCTIBLE, BOOST_FIT_JOIN *Documentation*
Some of those are documented. The others I could add some more comments in the code to what those do exactly.
Quite good butthe description of the semantic of the provided functions would need some extra wording. Maybe a section that states that the semantic expression is part of the constraints on the types.
What do you mean is part of the constraints on the type?
It takes too much pages to see what the library proposes.
For some functions we would need more information, examples. See below the detailed
*Potential usefulness of the library*
Very useful.
*Did you try to use the library? With which compiler(s)? Did you have any problems?***
Not tried yet.
*How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?***
In-depth study of the documentation (about 5 h for this revision).
*Are you knowledgeable about the problem domain?*
In general, yes.
*Were the concerns from the March 2016 review of Fit addressed?***
I believe ;-)
Best,
Vicente
*Documentation:*
In general:
* Navigation only from the top of the page
* Hyper links missing.
* There is no link to real code from the examples.
Most of the examples are a full running program that can be pasted in.
Good point.
Typo: last right parenthesis in
// Pipable sum
BOOST_FIT_STATIC_LAMBDA_FUNCTION(sum) = pipable([](auto x, auto y)
{
return x + y;
});
It is not clear if the following is correct in the body of a function
autosum = pipable([](auto x, auto y)
{
return x + y;
};
That needs to be corrected.
I was trying to keep the example simple. However, with the print out its a little more confusing.
Using is_detected, might be a little simpler, but it don’t think it would help overall.
I should add an implementation of those.
I believe that the range proposal woul include the pipe operator.
Although, there are some who don’t see the usefulness of it.
My question is how both pipe operator overloads interact.
How so?
That is a good idea.
Ok.
Typo?
Some parts of the documentation provides
*
http://pfultz2.github.io/Fit/doc/html/doc/src/concepts.html*ConstFunctionObject
I would like to note that this concept is not representable using the Concept TS as it is quantifying universally on the Ts (args) parameters.
The same applies to UnaryFunctionObject, BinaryFunctionObject
Wondering if the documentation should use the term Concepts then.
The purpose of the Concepts section is to document the type requirements. The current standard may not be able to check those type requirements in its current form, but there could be future versions of C++ that can check these type requirements.
The use of expresion "Is an object with ..." is confusing. What are we qualifying the type or the instance?
This means the type is an object(ie scalar, array, union, or class). Of course, an array or union cannot have a call operator, so this only applies to classes and scalars that are pointers.
Maybe it is worth defining FunctionObject.
Trye, although I never use that concept, it would make sense for completeness sake.
EvaluatableFunctionObject
It is not clear why this kind of FunctionObjects is useful
This mainly used by the `fit::eval` and `fit::apply_eval` functions.
Callable
I believe we have moved to call this Invocable in the standard. But again, I believe that you want to quantify universally the arguments, isn't it?
That is possible to check with the current C++(hence `is_callable`). This should be renamed to `Invocalbe` and `is_invocable`.
Does your definition of INVOKE differs from the one on the standard?
No, it shouldn’t, unless the standard doesn’t allow constexpr.
If yes, the differences should be mentioned. If not, the definition on the standard should be referenced.
Would cppreference be acceptable?
You use type T twice with different meaning
"The type |T| satisfies |Callable| if"
"if |f| is a pointer to member function of class |T|:"
I believe that here the T are not the same.
True, let me fix that.
Are final function objects Callable, ConstCallable?
Yes, why wouldn’t they be?
ConstCallable
The brief description is the same as the one for Callable
Is the definition of the second INVOKE different from the first one?
No, it isn’t. The only difference is the f is of type `const T`.
UnaryCallable
The name doesn't convey that it is *Const*Callable
Metafunction and MetafunctionClass
it is not clear what those are, there is no brief description. I guess that this applies to f.
What do you mean by a type or a template?
I see, that is a little confusing. These should follow the same definitions as in Boost.MPL.
Good point.
It is not clear how by_adaptor<Projection, F> and by_adaptor<Projection> can be used by the user?
I could add an example using std::map.
Shouldn't those be hidden?
No they shouldn’t be hidden.
This is a genral remak, why F must be ConstCallable?
For the same reason everything is ConstCallable.
*
http://pfultz2.github.io/Fit/doc/html/include/boost/fit/compose.html *The requirements don't state clearly the constraints on the input parameters of f and the result of g, except by the semantic expression. This is a general remark. I suspect that you mean the semantic expression must be well formed. But, is this SFINAE friendly or is this a requirement?
It is sfinae-friendly.
Can both function be final function objects? ****
In compose? Any of the functions can be final.
Yes, it takes any `ConstCallable`
Typo "Proposal for C++ Proposal for"
P0051 original proposal uses overload_linearly/overload (as Boost.Hana) instead of conditional/match. Wondering if those names aren't more clear.
I really hate the name overload_linearly. Its long and doesn’t describe what it does.
Why do we need to change the Boost.Hana names?
Those names were chose before Boost.Hana. I use `conditional` because it was like a conditional block, especially when used with fit::if_. Perhaps, there is a better name.
There is also std::conditional :(
Which really should’ve been called std::if_.
Can more than 2 parameters be final function objects?
Yes, of course.
True, let me update the documentation.
Yes.
Shouldn't StaticFunctionAdaptors have Functions as parameters?
What do you mean?
I named the `auto_cast` function `explicitly` to do a explicit conversion.
Other uses of this pattern I've see are to create a buffer able to store a specific struct
struct S;
S* ptr = create_msg();
create_msg returns an class that is convertible to a T* and that allocates sizeof(T) bytes of memory.
Ah yes, for that too.
Why this pattern respect the DRY principle (we don't repeat S), I believe it abuses of implicit conversions.
Well, there is a caveat when someone uses ``auto`, like in your example:
auto ptr = create_msg();
There is a guard to prevent this, but it doesn’t work in C++17.
That is true if `f` is a pointer, but is not true for all dereference operators.
*
http://pfultz2.github.io/Fit/doc/html/include/boost/fit/infix.html***
One of the asked infix operations is pow. However we would like to evaluate from right to left and have the higher precedence than * x pow ypow z===pow(x, pow(y,z))
x * ypow z===x * pow(y,z) x pow y* z===pow(x,y) * zWith the proposed infix notation this should be written
x <pow> (y<pow> z)===x * pow(y,z) x * (y<pow> z)===x * pow(y,z) (x <pow> y)* z===pow(x,y) * z
and the following would be surprising
x <pow> y<pow> z===pow(pow(x, y, z) x * y<pow> z===pow(x * y, z) x <pow> y*z===pow(x, y * z) It would work better for swap or compare (proposed operator <=>) as these functions are not associative. I believe a note should prevent the users for such bad use cases, for which it is better to don't define the infix operator.
That is a good example to talk about. I will add that.
That seems more related to fit::partial.
There is no way to safely manage the lifetime with a reference.
Is there a safe way to use MutableFunctionObjects with Fit?
Yes, you can use `std::ref.
That is true, since it decays the parameters.
No.
Shouldn't it be MoveConstructible?
No, it is not necessary. Pipable does not capture the parameters by value, since it is almost always used in the same expression(ie `x | f(y)`).
When you want `bind` or `lazy` to capture a bind expression instead of evaluating it.
Is there a typo here
assert(lazy(f)(protect(lazy(g)(_1)))() == f(lazy(g)(_1))) ^ Shouldn't it be assert(lazy(f)(protect(lazy(g)),_1)() == f(lazy(g)(_1)))
Nope, that is correct.
It also adds a `result_type` to the function. Its mainly used to annotate function with the result type, which can be useful for fit::fix or Boost.Variant visitors. The documentation could make this clearer.
You mean the table of contents? Yea, for them to appear there they need to be moved to a different section, with a header for each section.
True, it is right fold with the arguments flipped.
STATIC_FUNCTION just declares a function objects at namespace or global scope, which requires the function to be constexpr constructible. The `static_` adaptor is to declare an adaptor that does not have a constexpr constructor.
First, it doesn’t have the same signature as std::apply. Secondly, its very confusing, as ‘apply' generally means function applications especially in boost. So I would like to avoid this confusion.
Need to introduce the Sequence concept and how it is customized?
Hmm that is probably a better way to define it.
unpack_sequence? How unpack_sequence is used by unpack?
Not every sequence could be defined with indices.
Is unpack_sequence defined if the class defines the tuple-like traits?
No because they are not sfinae-friendly.
Aside the example, it is not defined what the user must define.
That could probably use more explanation.
What the member function apply must return?
The result of calling `f`.
How the unpack_sequence parameter and the Sequence parameter of member function apply are related?
I don't understand
template<class F, class Sequence>
constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS
(
s(std::forward<F>(f))
); Is a Sequence a callable taking a Callable or there is a type here? Is there a missing return?
I suspect it should be
template<class F, class Sequence>
constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS
(
std::forward<F>(f)(s0, ,, sk);
);
If this is correct, does it means that unpack just forwards to unpack_sequence?
That example, I guess is a little confusing. As the `Sequence` is a function like fit::pack, but yes unpack calls unpack_sequence to do the unpacking for a single sequence.
Does the default specialization make use of INVOKE?
Its not needed, as the function passed to `unpack_sequence` will always have a call operator.
You can’t capture by value or reference dependending if it is an lvalue when using lambda captures.
Essentially yes. There is no call operator when its false.
Yes its still useful, as it only sets a max limit.
True, but the first call to repeat doesn’t need to be unary.
This is to match how placeholders work. So arg<1> and _1 are the same number.
Could you add a rationale in the doc?
Yea.
Do you have a link?
What happens when the parameter is not a T is not constructible from the params? SFINAE?
Yes.
What happens when the parameter is not a MetafunctionClass? SFINAE?
Yes.
I believe Boost.Hana uses make instead of construct.
That is a possible name.
It doesn’t always copy, like when passing reference_wrapper.
It can be treated as a function. I should update the synopsis to use a function signature instead.
Ah, it could cause collision if users do `using boost::fit`.
It is a metafunction(doing ::type works), but its actually more like a type trait.
Its not like std::apply, its like hana::apply. Of course, maybe I could rename this to fit::invoke, and then add a fit::apply, that only calls the call operator.
There isn’t a way. Perhaps I could add PP define to change it, but I wonder if its better to have some way to change it on a per-variable basis.
That maybe a better approach. Maybe I can call it BOOST_FIT_LIFT_FUNCTION.
fit::capture uses fit::pack, but also does a pack_join to combine the pack and the parameters together.
I am not that familiar with unix tee.