Boost :

Date view	Thread view	Subject view	Author view

Subject: Re: [boost] Fit review - viboes
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-09-10 09:53:46

Next message: Ion GaztaÃ±aga: "Re: [boost] How to deal with unused variable with a BOOST_ASSERT check?"
Previous message: Emil Dotchevski: "Re: [boost] How to deal with unused variable with a BOOST_ASSERT check?"
In reply to: P F: "Re: [boost] Fit review - viboes"
Next in thread: P F: "Re: [boost] Fit review - viboes"
Reply: P F: "Re: [boost] Fit review - viboes"

First sorry for the formatting of my original post.

Le 09/09/2017 Ã 22:22, P F a Ã©critÂ :
>
>> On Sep 9, 2017, at 6:27 AM, Vicente J. Botet Escriba via Boost
>> <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
>> *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.

Sorry I missed this section :(
>
>>
>> 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 not talking about any traits. is_callable is special in the sense
there is an equivalent in the C++ standard (is_invocable).
I don't think we should require that all the traits in Boost.Traits
should be compatible C++98 when we are already in C++17.
>
>>
>> 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).

Why not call it invoke?
>
>>
>> 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}`.

This will be useful.
>
>> 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).

An example will be welcome in the documentation.
>
>> 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.

E.g.

assert(compose(f, g)(xs...) == f(g(xs...))); If f and g don't compose, would compose(f, g) SFINAE the
operator() or just compile fail. If it SFINAE, I could use compose(f, g)
to check if f and g are composable.

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

Oh, I see it now.

I believe there is however an issue when you have more than one final
function objet. Do you have a test with two function objects?
If I remember the issue was because we can not inherit from two wrapper
classes doing perfect forwarding.
If you don't have the issue, I will base my implementation of the
proposed overload on your implementation ;-)
>
>> *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).
>
>>
>> Possible files contains details that could be shared in Boost or used
>> from other Boost libraries
>>
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/move.hpp
>> - I believe Hana use something like this also to reduce the
>> dependencies (compile footprint)
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.hpp
>
> 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.

What I mean is that IMHO Boost should solve these issues in a single
way. If we don't want to use directly e.g. <utility> because it is
heavy, we should provide the lighter components in Boost. I don't
believe it is a good approach to redefine them in each library that
needs such basic facilities..
>
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/noexcept.hpp
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/and.hpp
>> - I believe Hana use something like this also to reduce the
>> dependencies (compile footprint)
>
> Well, I dont know of a library in boost that implements the fast_and
> algorithm that works on gcc 4.6+ and msvc.

We have std::conditional. If we have a better option (for some compiler
version) this should go to the Core library as any library could profit
from it. This is a basic feature.
>
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compressed_pair.hpp
>
> 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.

My comment included shared. If your compressed pair is better, we should
improve Boost.CompressedPair.
>
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/constexpr_deduce.hpp
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/intrinsics.hpp
>
> This probably could be factored out in a separate boost library, which
> might be useful for other heavy metaprogramming libraries.

This is my point.
>
>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/pp.hpp
>> https://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.

Yes this would help to understand what the code is doing in detail. I
understand that you want to follow DRY principle, but this makes the
code more difficult to understand until we are familiar with the macros.
>
>>
>> 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?

Usually we describe the expressions that the types must support on the
requirements. You use a semantic clause as requirement. What I mean is
that the semantic clause implies the expression must be well formed and
so is a requirement on the concerned types. That is the semantic
expression isÂ used to define what the function does and is also
contains constraints of a not named Concept. What I would like is split
the requirements and what the function does.
>
>>
>> *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.

Humm, I don't see the include on the code fragments, the needed using
namespace, ...
>
>>
>>
>> In particular:
>>
>> *http://pfultz2.github.io/Fit/doc/html/doc/src/gettingstarted.html*
>>
>> An explanation of the BOOST_FIT_LIFT limitations would be more than
>> welcome.
>
> Good point.
Could you tell us here what they are? in detail?
>
>>
>> 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
>>
>> auto sum Â = Â pipable([](auto Â x, Â auto Â y)
>> {
>> Â Â Â return Â x Â + Â y;
>> };
>
> That needs to be corrected.

Could you confirm that the previous code without using the
BOOST_FIT_STATIC_FUNCTION is valid?
If yes I believe that the documentation could use this form as far as it
is inside the body of a function.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/doc/src/example_print.html*
>>
>> I would suggest to use an heterogeneous tuple in the
>> for_each_tupleexample.
>>
>> In addition use some kind of brackets to print the sequences and the
>> tuples would help to identify what is been printed.
>
> I was trying to keep the example simple. However, with the print out
> its a little more confusing.

This is my point.
>
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/doc/src/example_overloading.html*
>>
>> Typo:
>>
>> Before
>> // Check that T has member function for operator* and ope

>> After // Check that T has member function for operator* and operator->

Note the typo above.
> *http://pfultz2.github.io/Fit/doc/html/doc/src/more_examples.html*
>>
>
>>
>> My question is how both pipe operator overloads interact.
>
> How so?

My bad. Each overload applies to different types, so that there
shouldn't be no conflict.

BTW, is operator|() defined only for pipable_adaptor<F>?

Could the user define a function object that is a pipable_adaptor for
your library and it is also a pipable_xxx for the range library?

>
>>
>>
>>
>
>>
>> Static Function Adaptor
>>
>> I would say "It has an additional requirement that the
>> *class****function* is |DefaultConstructible|:"

Don't forget this one.
>>
>>
>>
>> *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.

No, they couldn't if they are based on the Concept TS. The Concept TS
doesn't have universal quantification, and I believe it wouldn't never
had it from what the authors think about this feature.
>
>>
>>
>> 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.
I believe it is better to use the term "type" here.
>
>>
>> EvaluatableFunctionObject
>>
>> It is not clear why this kind of FunctionObjects is useful
>
> This mainly used by the `fit::eval` and `fit::apply_eval` functions.

I mean, it is not clear in this section, and some clarification is
needed here.
>
>>
>>
>> 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`.

Well is_invocable requires to know the type of the arguments. I believe
that your Callable doesn't require to know with with types the function
can be called. Could you confirm?
Anyway, as the standard uses is_invocable and the concept is based on
INVOKE you should use 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?
I would reference both then.
>
>>
>> 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.
cppreference has the same error :(
>
>>
>> Are final function objects Callable, ConstCallable?
>
> Yes, why wouldnâ€™t they be?

Ok. I missed that.
>
>>
>>
>> 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`.

I believe it is not worth duplicating the description for this
difference. Just say reference the standard and say INVOKE(...) is valid
with a const T object or a non-const object.
>
>>
>> UnaryCallable
>> The name doesn't convey that it is *Const*Callable

Any concern here?
>>
>> 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.

Wondering if it isn't better to reference (and copy if you want the
definition)
>
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/by.html*
>>
>>
>> It is not clear to me what
>>
>> by(p)(xs...) Â == Â p(xs)... mean
>>
>>
>> An example of `fit::by` without a function argument will be welcome.
>
> 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.

We should add some real example as motivation. Maybe not here, in the
tutorial.
>
>
>>
>> *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.
Could you add it to the reference documentation. This is an important
feature.
In the standard they use "This function should not participate in
overload resolution until ... or something like that.
>
>> Can both function be final function objects? ****
>
> In compose? Any of the functions can be final.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/conditional.html*
>> It is not clear what king of parameters this function could have (in
>> particular in comparison with P0051). Does it accept function/data
>> members pointers, final classes, references_wrappers, â€¦?
>
> Yes, it takes any `ConstCallable`
Sorry, I missed the specific nature of 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.

I don't find that conditional/match describe what they do. This is the
eternal naming issue :)
>
>> 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.

Sure. I don't think you should use conditional, as we have
std::conditional, we a really different meaning.
>
>> There is also std::conditional :(
>
> Which really shouldâ€™ve been called std::if_.
Too late. The standard committee doesn't like names as if_, mutable_,
int_ :(
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/implicit.html*
>>
>> Is implicit a StaticFunctionAdaptor?
>
> Yes.
>
>> Shouldn't StaticFunctionAdaptors have Functions as parameters?
>
> What do you mean?
That implicit has a template, not a class :(
>
>> 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();
yes, this is the caveat of returning a proxy that is convertible to
anything. Could you warm the user in the documentation of this possible
bad usage?
>
> There is a guard to prevent this, but it doesnâ€™t work in C++17.
Could you elaborate?
>
>> http://pfultz2.github.io/Fit/doc/html/include/boost/fit/indirect.html
>> Wondering if it could be worth adding some preconditions as I guess
>> that the function call
>>
>> indirect(f)(xs...)
>>
>> will be undefined if f is null
>
> That is true if `f` is a pointer, but is not true for all dereference
> operators.

For example?
>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lazy.html*
>> Note p0356r1. It would be good to have a comparison in order either
>> to improve the proposal or your library.
>
> That seems more related to fit::partial.
Correct.
>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/match.html*
>> Same comments than for fit::conditional. What are ex typo "Proposal
>> for C++ Proposal for"
>> Can more than 2 parameters be final function objects?

>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/mutable.html
>> *Example of bad usage would be welcome.**Why Fit uses always const?
>> **Why not use a reference to the function object instead?
>
> There is no way to safely manage the lifetime with a reference.
I was talking of reference_wrapper.

IIUC, mutable should be used *only* to wrap existing functions that
where no const but that don't modify the object (but it is a3rd party
code and cannot be changed). I'm wrong?

>
>> Is there a safe way to use MutableFunctionObjects with Fit?
>
> Yes, you can use `std::ref.

But reference_wrapper is a ConstFunctionObject.
I mean when mutable_ is safe? The 3rd party use case?
Do you have a good example of MutableFunctionObject that is safe?
After all I wonder if Mutable is the correct name. In C++ mutable means
modifiable by a const function. I'll suggest NonConst as the function
applicable to non-const objects.
>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/partial.html*
>> Are there any constraints on the type of xs. Shouldn't them be
>> MoveConstructibles?
>
> That is true, since it decays the parameters.

This kind of information is useful.
>
>> http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pipable.html.
>
>> 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)`).
Ok, I see.
>
>
>> http://pfultz2.github.io/Fit/doc/html/include/boost/fit/protect.html
>> It is not clear to me what this useful for. Could you elaborate?
>
> When you want `bind` or `lazy` to capture a bind expression instead of
> evaluating it.

and ... could you elaborate? Could you show how we can do it without
fit::protect and with?
>
>> 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 is incoherent with the example. So maybe the example is wrong

auto lazy_apply = lazy(apply)(protect(lazy_id), _1);` Or I'm missing something

>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/result.html***
>> This adaptor converts explicitly the result of the call to the type.
>> Have you considered `convert_to`?
>
> 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.

Yes, I know that knowing the result type allows to optimize visitors.
What is the main intent? to force the conversion or to have a way to
retrieve the result type of a function object? The name should convey
the main intent.
We have std::result_of until C++14 and invoke_result since C++17 to get
the result type.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html*
>>
>> as_failures, with_failures, .... Â /adaptors/ don't appear on the index.
>
> 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.
You have items in the index that don't have his own file, e.g.
http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#unamed-placeholder,
so you should be able to add to it anything without needed a file, isn't it?
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reverse_fold.html*
>>
>> reverse_fold is not right fold, as right fold is right associative,
>> isn't it?
>
> True, it is right fold with the arguments flipped.

right fold don't flip the argument ;-)
This is way reverse_fold is a good name, otherwise it should be named
fold_right
>
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/rotate.html***
>> Could you show a concrete use case?
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/static.html***
>>
>> What are the differences of this adaptor and the macro STATIC_FUNCTION?
>
> 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.

It is weird the example don't show the specific case as it uses static_
at global global scope. Could you show another example that is not at
the namesapce o global scope.

Why static_ couldn't declare its default constructor constexpr? I
believe the description is on the other sense, which is why it is
confusing. static_ requires a default constructor but don't requires the
constructor to be constexpr and don't provides one constexpr default
constructor, but I suspect that if the default constructor is constexpr
it should work also. IIUC, you are saying that if it is the case then it
is better to use the macro BOOST_FIT_STATIC_FUNCTION.

>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack.html*
>>
>> Why name it unpack instead of apply like in C++17?
>
> First, it doesnâ€™t have the same signature as std::apply.

Because you curry the function?
> Secondly, its very confusing, as â€˜apply' generally means function
> applications especially in boost. So I would like to avoid this confusion.

We are doing a function application here, isn't it?
>
>> 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?
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack_sequence.html***
>> Why unpack_sequence, and not the tuple-like traits?
>
> Not every sequence could be defined with indices.
For example?
>
>> Is unpack_sequence defined if the class defines the tuple-like traits?
>
> No because they are not sfinae-friendly.
Why? Could you elaborate?
>
>> 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`.

These things need to be defined in the documentation.

When a user specialize unpack_sequence, what are the constraints of the
parameter F. Should it be ConstCallable?
>
>> 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.
Please, fix it.
>
>> Does the default specialization make use of INVOKE?
>
> Its not needed, as the function passed to `unpack_sequence` will
> always have a call operator.
I was talking of what the *default* specialization for tuple does.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/capture.html***
>> Please, could you show how it is more flexible than lambda captures
>> in C++?
>
> You canâ€™t capture by value or reference dependending if it is an
> lvalue when using lambda captures.

This merits a concrete example in the documentation just after you say
"It provides more flexibility in capturing than the lambda capture list
in C++" or at least have here a link to a rationale section.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/if.html*
>>
>> What happens when the parameter is false_type? SFINAE?
>
> Essentially yes. There is no call operator when its false.

This merits to be said in the documentation.
>
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat.html*
>>
>> Add requirement on the function parameter that must be a Unary
>> function such that f(f(x)) is well formed.
>
> True, but the first call to repeat doesnâ€™t need to be unary.
And what it could be? You lost me.
>
>>
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/arg.html***
>> What is the rational for the choice of been 1-based?
>
> This is to match how placeholders work. So arg<1> and _1 are the same
> number.
I was sure that you had a good reason:)
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/construct.html*
>>
>> Maybe add a reference to the factory proposal p03382.
>
> Do you have a link?
:)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0338r1.pdf

>
>>
>> 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.
Please, document it.
>
>>
>> I believe Boost.Hana uses make instead of construct.
>
> That is a possible name.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/decay.html*
>>
>> Why not decay_copy?
>
> It doesnâ€™t always copy, like when passing reference_wrapper.

It copies the reference_wrapper, isn't it?
>
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html***
>> Wondering if it is not better to locate them in a placeholders
>> namespace, so that we can avoid possible collisions with other
>> placeholders.
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#unamed-placeholder*
>>
>> The same here
>
> Ah, it could cause collision if users do `using boost::fit`.
Would you move to a nested placeholders namespace?
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function_param_limit.html***
>> |function_param_limit is not a Metafunction.
>> "|The|function_param_limit| Â metafunction Â â€¦"
>
> It is a metafunction(doing ::type works), but its actually more like a
> type trait.
Right. Please fix it.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/is_callable.html***
>> F must be Callable can not be a requirement ;-)
>>
>> Add reference to C++17 trait is_invocable.
Please fix this.
>>
>> Wondering if we should have it in type_traits, if not already there.
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/apply.html***
>> Confusion with std::apply. is this related to std::invoke?
>
> Its not like std::apply, its like hana::apply.

I know that it is not like std::apply, hence the possible confusion.
> Of course, maybe I could rename this to fit::invoke, and then add a
> fit::apply, that only calls the call operator.

I don't see any reason to use a different name when the function are
curried.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function.html*
>>
>> "By default, all functions defined with|BOOST_FIT_STATIC_FUNCTION|
>> Â use thereveal
>> <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html>
>> Â adaptor to improve error messages."
>>
>> How to change this default?
>
> 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.
No problem. My comment was due to this sentence. I believed that there
were a way to change it.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lift.html***
>> WhyBOOST_FIT_LIFT_CLASSdoesn't defines a instance as do
>> BOOST_FIT_STATIC_FUNCTION?
>
> That maybe a better approach. Maybe I can call it BOOST_FIT_LIFT_FUNCTION.
Right.
>
>>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pack.html***
>> How this is related with fit::capture?
>
> fit::capture uses fit::pack, but also does a pack_join to combine the
> pack and the parameters together.
We need some examples of these uses.
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/tap.html*
>>
>> How this is related to the tee unix command?
>
> I am not that familiar with unix tee.
https://en.wikipedia.org/wiki/Tee_(command)
>
>>
>> *http://pfultz2.github.io/Fit/doc/html/doc/src/configurations.html***Which
>> ones?
>>
There are none now. Are there some or should this section be removed?

Vicente

Next message: Ion GaztaÃ±aga: "Re: [boost] How to deal with unused variable with a BOOST_ASSERT check?"
Previous message: Emil Dotchevski: "Re: [boost] How to deal with unused variable with a BOOST_ASSERT check?"
In reply to: P F: "Re: [boost] Fit review - viboes"
Next in thread: P F: "Re: [boost] Fit review - viboes"
Reply: P F: "Re: [boost] Fit review - viboes"

Date view	Thread view	Subject view	Author view

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk