Re: [boost] [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2014-07-29 14:41:45

Hi Louis,

Louis Dionne wrote:

> Dear Boost,
>
> It has been a while since I've given news about my GSoC project,
> Boost.Hana[1].
> Things are going very well and I uploaded the library to the Boost
> Incubator.
> I think it is time to push the library forward for review.

I've looked through much of the documentation, and this looks really good.
I was impressed with your post on improved performance using lambdas, but I
was concerned about it being very cumbersome.  I really like the syntax
you've developed.

Regarding performance, I note that you have several graphs in the reference
section showing (generally) good performance scaling.  I think it would be
useful to add a section to the manual speaking generally about
performance.  One common criticism of metaprogramming is the time it takes
to compile and link.  Addressing it would certainly help someone understand
more benefits of the library without having to follow the boost list.

I have a few other suggestions about the documentation that I can send
along, if you're looking for that at this point.

As the author, I know everything that's left to be done and polished before
> I can be fully satisfied. Still, I believe the library is worthwhile in its
> current state as it implements a superset of the functionality found in the
> Boost.MPL and Boost.Fusion. I also think the library will benefit greatly
> from a larger user base and more feedback.
>

It sounds like you're already planning to do this, but mentioning
type_list<>, even if it's essentially just list(type<>...) would help show
that this is a valid replacement for MPL.

Do you plan to implement things like MPL's vector_c?  I ask because a C++14
units library could be much nicer than the (already nice) boost units
library.  Using Hana could be nice for compile times.

> Here are some caveats:
> - The library requires a full C++14 compiler, so only Clang 3.5 can compile
>   the unit tests right now. However, compilers will eventually catch up.
>   Also, pushing cutting edge libraries forward might motivate compilers to
>   support C++14 ASAP, which is probably a good thing.
>

I would have no problem with a C++14-only requirement.  It would definitely
slow adoption, but I'd rather the code stay more pure and performant.  As
others have noted, we have fallbacks.

My only concern would be the performance on other compilers once they
implement the necessary features.  Is there some assurance that the lambda
trick would work (i.e. be fast) on g++?

I look forward to playing with this in about a month.  I'll definitely post
a review if and when a review occurs.

Thanks,
Nate