[boost] [review][Fit] Review of Fit starts today : September 8 - September 17

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[boost] [review][Fit] Review of Fit starts today : September 8 - September 17

Boost - Announce mailing list
A formal review of the Fit library developed by Paul Fultz II starts
today, September 8, and runs through September 17.

A branch has been made for the review. You can find Fit for review at
these links:

Source: https://github.com/pfultz2/Fit/tree/boost
Docs: http://pfultz2.github.io/Fit/doc/html/doc/

Anyone who is able to provide an assessment of the design,
implementation, and/or docs can participate in this review. Usage
experience is not absolutely necessary to give feedback, but is highly
recommended if you are writing a review. Discussions about aspects of
the library are welcome even if a complete review is not presented,
though participants are asked to please state whether they would like
to accept or reject the library before the deadline of September 17,
paying close attention to the questions raised at the end of this
email. The success of Boost is partially a result of the quality
review process which is conducted by the community. You are part of
the Boost community. We will be grateful to receive a review based on
whatever level of effort or time you can devote.

This is the second time that Fit will go through the review process,
with the previous time being in March of 2016. The result of the
initial review can be found here:
https://lists.boost.org/Archives/boost/2016/04/228770.php

In this second review, those who choose to participate should be as
rigorous as they'd be in any other review, but are also encouraged to
voice whether or not the concerns from March of 2016 were addressed.

The following is a brief description of the library from its author:

====================

Fit is a header-only C++11/C++14 library that provides utilities for
functions and function objects, which can solve many problems with
much simpler constructs than whats traditionally been done with
metaprogramming.

Fit is:

Modern: Fit takes advantages of modern C++11/C++14 features. It
support both constexpr initialization and constexpr evaluation of
functions. It takes advantage of type deduction, varidiac templates,
and perfect forwarding to provide a simple and modern interface.

Relevant: Fit provides utilities for functions and does not try to
implement a functional language in C++. As such, Fit solves many
problems relevant to C++ programmers, including initialization of
function objects and lambdas, overloading with ordering, improved
return type deduction, and much more.

Lightweight: Fit builds simple lightweight abstraction on top of
function objects. It does not require subscribing to an entire
framework. Just use the parts you need.
Fit is divided into three components:

Function Adaptors and Decorators: These enhance functions with
additional capability.
Functions: These return functions that achieve a specific purpose.
Utilities: These are general utilities that are useful when defining
or using functions.

Requirements

This requires a C++11 compiler. There are no third-party dependencies.
This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio
2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported.


Contexpr support:

Both MSVC and gcc 4.6 have limited constexpr support due to many bugs
in the implementation of constexpr. However, constexpr initialization
of functions is supported when using the FIT_STATIC_FUNCTION and
FIT_STATIC_LAMBDA_FUNCTION constructs.


Noexcept support:

On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used
due to many bugs in the implementation. Also, most compilers don’t
support deducing noexcept with member function pointers. Only newer
versions of gcc(4.9 and later) support this.

====================

Please provide in your review whatever information you think is
valuable to understand your final choice of ACCEPT or REJECT including
Fit as a Boost library. Please be explicit about your decision.

Some other questions you might want to consider answering:

 - What is your evaluation of the design?
 - What is your evaluation of the implementation?
 - What is your evaluation of the documentation?
 - What is your evaluation of the potential usefulness of the library?
 - Did you try to use the library? With which compiler(s)? Did you
   have any problems?
 - How much effort did you put into your evaluation? A glance? A quick
   reading? In-depth study?
 - Are you knowledgeable about the problem domain?
 - Were the concerns from the March 2016 review of Fit addressed?

More information about the Boost Formal Review Process can be found here:
http://www.boost.org/community/reviews.html

Thank you for participating!

--
-Matt Calabrese

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce
Reply | Threaded
Open this post in threaded view
|

Re: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17

Boost - Announce mailing list
On Fri, 8 Sep 2017 07:02:27 -0400
Matt Calabrese via Boost via Boost-announce
<[hidden email]> wrote:

> A formal review of the Fit library developed by Paul Fultz II starts
> today, September 8, and runs through September 17.
>
> A branch has been made for the review. You can find Fit for review at
> these links:
>
> Source: https://github.com/pfultz2/Fit/tree/boost
> Docs: http://pfultz2.github.io/Fit/doc/html/doc/
>
[...]

>
> Requirements
>
> This requires a C++11 compiler. There are no third-party dependencies.
> This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio
> 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported.
>
>
> Contexpr support:
>
> Both MSVC and gcc 4.6 have limited constexpr support due to many bugs
> in the implementation of constexpr. However, constexpr initialization
> of functions is supported when using the FIT_STATIC_FUNCTION and
> FIT_STATIC_LAMBDA_FUNCTION constructs.

`FIT_LIFT` uses `auto` in a C++14-style lambda, and thus does not
compile when in C++11 mode.

>
> Noexcept support:
>
> On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used
> due to many bugs in the implementation. Also, most compilers don’t
> support deducing noexcept with member function pointers. Only newer
> versions of gcc(4.9 and later) support this.
>
> ====================
>
> Please provide in your review whatever information you think is
> valuable to understand your final choice of ACCEPT or REJECT including
> Fit as a Boost library. Please be explicit about your decision.

I would vote to accept the library.

> Some other questions you might want to consider answering:
>
>  - What is your evaluation of the design?

Overall I have a positive impression of the design. In general there is
a logical consistency to the adaptors / decorators.

The `infix` operator still feels like a gimmick - why include it in the
library? I cannot think of an instance where I would use such a
utility, especially considering the fragility of operator precedence.

>  - What is your evaluation of the implementation?

I think there are too many macros internally, but I think its mostly to
work around compilers. So its about average for a boost library. I also
do not like the inheritance from user-callables, as it seems
unnecessary in some cases (although perhaps easiest for `match`, etc.?).

>  - What is your evaluation of the documentation?

The documentation seems to be improved from what I remember. At first I
felt like the getting started and examples section was "too much too
fast", but I am not sure there is an easy way to introduce a programmer
to some of these concepts. Is the library inspired by another, or
entirely by "point-free programming"? I am trying to think of some
outside resource to reference, but I cannot think of any.

>  - What is your evaluation of the potential usefulness of the library?

Some of the utilities will be valuable for C++11 projects (move
capture), and I also like the "pack" handling functions that will not
be available until C++17. A number of the adaptors seem like they could
be useful, but I've also not written anything similar or considered
doing so. Which might mean I need to do more functional programming.

>  - Did you try to use the library? With which compiler(s)? Did you
>    have any problems?

This time I just used the `BOOST_LIFT` function, tried out the
auto-placeholder and pipable adaptor to study their behavior.

>  - How much effort did you put into your evaluation? A glance? A quick
>    reading? In-depth study?

I spent significantly more the first review, particularly with the
implementation. I spent only a 1-2 hours looking at the code /
documentation this time.

>  - Are you knowledgeable about the problem domain?

This is a fairly unique project; I do not know specifics about this
type of point-free or functional programming. I am fairly familiar with
std/boost bind and the usage of basic callables.

>  - Were the concerns from the March 2016 review of Fit addressed?

I brought up inheritance from user types as a potential issue. The
author disagreed? A small implementation quirk, but can lead to
surprising behavior with operator overloads, etc.

I also suggested (i.e. not a concern necessarily) that the placeholders
be placed into their own namespace. This would allow
`using boost::fit::placeholders` without bringing the entire
`boost::fit` namespace into scope. The library could still alias the
placeholders into the `boost::fit` namespace as well.

There is also this strange oddity:

    struct {
        int operator()(int x, int y = 10) const noexcept {
            return x + y;
        }
    } sum{};
    const auto pipe_sum = boost::fit::pipable(sum);

    int main() {
        std::cout << (1 | pipe_sum) << std::endl;
        return 0;
    }

The function is immediately evaluated, without `()` on pipe_sum and
outputs `11`. I looked through my post last time, and recommended that
something in the documentation mention that `pipable` behaves like a
`partial` evaluation. Or again, maybe that's obvious from the pack
listed in the documentation? So while the partial evaluation might be
obvious due to the documentation, the immediate evaluation without the
extra `()` is still intriguing.

> More information about the Boost Formal Review Process can be found
> here: http://www.boost.org/community/reviews.html
>
> Thank you for participating!
>

Lee
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce