Re: [boost] Boost.Hana

Subject: Re: [boost] Boost.Hana
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-07-07 14:19:21

Glen Fernandes <glen.fernandes <at> gmail.com> writes:

>
> Dear Ron, Louis, and Boost developers,
>
> The review period for Hana has concluded. 18 reviews were submitted:
> - 17 votes for acceptance. (1 of these was conditional upon Hana
>   wholly supporting a second C++ implementation however).
> - 1 vote for rejection; for lack of compiler support.
>
> I submit that Hana be accepted into Boost. I want to congratulate Louis:
> the Boost community wants Hana to become an official Boost library.
> Thank you again, Louis, for your work on Hana and for contributing it
> to Boost.

Thanks a lot to you for managing the review. I'd also like to thank everyone
who participated in the review, and everyone who was involved with Hana since
its inception.

I think this is a big step for C++ metaprogramming, and I also think this
is a nice step for the C++ language as a whole. Indeed, if some people start
using this library, compiler vendors will _have_ to support C++14 properly,
which will contribute to pushing the language forward. I also hope some
techniques or ideas found in this library can find their way into the
standard library.

> I propose we require, prior to Hana's inclusion in a Boost release, only
> that:
> 1. Hana's unit tests to be integrated into Boost's regression tests. If
>    this requires maintaining both CMakeLists.txt and .b2 files, it is
>    still worth it. I am willing to assist with this effort (and the
>    invitation extends to anyone in the community to also contribute to
>    the task). For release managers, potential Hana contributors, or just
>    the general developer community in Boost, to see Hana's test cases in
>    http://boost.org/development/tests/master/developer/summary.html will
>    be useful.

Agreed. When you say "integrated into Boost's regression tests", does this
mean it would be OK if the test matrix could be updated from Travis-ci?
If that was sufficient and possible with Travis, that would be the best
way by far because these tests are run on each push. Otherwise, I'll make
the tests usable from Boost.Build.

> I trust, but do not mandate before Hana is officially accepted into
> Boost, that:
> 1. All GitHub issues pertaining to implementation and documentation that
>    were opened by Louis in response to review feedback (or by others,
>    such as Vincente, that were approved by Louis) will be addressed
>    eventually (as long as they remain relevant).

Of course, this is a long shot, but I will work towards that goal.
Also, I'd like to invite anyone willing to help to join this effort.

> I personally would ask for, but do not require for Hana's acceptance,
> that:
> 1. That Hana's non-reference documentation live outside of the source
>    code. The presentation of Hana's documentation is great; it looks
>    modern, is easy to browse. I am not a fan of the prose living inside
>    hana.hpp though (API reference documentation is the only exception).

I've been thinking about this, too. I'll put this in an external markdown
file. See this issue [1].

> 2. Louis to investigate further the possibility of a Hana core library
>    if such can be achieved with zero overhead (instead of focusing that
>    effort onto a separate library that provides only a subset of Hana's
>    functionality).

I'm currently working on a rather large patch which modularizes Hana.
Basically, the goal is to have

    boost/
        hana/
            tuple.hpp -> only the tuple implementation
            xxx.hpp -> only the xxx algorithm
            concept/
                XXX.hpp -> stuff related to the XXX concept

What this would mean is that you can include only hana/tuple.hpp and get
a lightweight and very efficient tuple implementation, and then include
only the algorithms you need. Right now, the only choice is to include
all the algorithms along with tuple.hpp, which I think was a design mistake.

This patch will also make it much easier to fix other bugs, some of which I
already have a fix for but can't apply it due to tight coupling.

> On the note of Hana's current support in existing C++ implementations:
> - While Hana is wholly only supported by clang at present, gcc is not
>   far behind. Given the trend of language conformance, it is reasonable
>   to expect Hana will be entirely supported in a future gcc release.

Correct. We're not too far with GCC, especially if the library can spur
interest and push more people to file bug reports.

> [...]
>
> My thanks to everyone that participated in Hana's review with a
> review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel,
> Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul,
> Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug
> reports.
>
> Best,
> Glen

Regards,
Louis

[1]: https://github.com/ldionne/hana/issues/161