Re: [boost] [Hana] Formal review

Subject: Re: [boost] [Hana] Formal review
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-18 00:23:36

On 6/17/2015 3:55 PM, David Sankel wrote:
> On Wed, Jun 10, 2015 at 3:19 AM, Glen Fernandes <glen.fernandes_at_[hidden]>
> wrote:
>
>> - Whether you believe the library should be accepted into Boost
>>    * Conditions for acceptance
>>
>
> Yes, I think it should be accepted into Boost. The one condition is that
> the library works with release versions of at least two different
> mainstream C++ compilers. More on that later...
>
>
>> - Your name
>>
>
> David J. Sankel
>
>
>> - Your knowledge of the problem domain.
>>
>
> I've written numerous libraries that make use of Boost.MPL and
> Boost.Fusion. I also have quite a bit of functional programming expertise.
>
>
>>
>> You are strongly encouraged to also provide additional information:
>> - What is your evaluation of the library's:
>>    * Design
>>
>
> The core technique of combining value and type expressions is solid and
> makes metaprogramming easier and, as a bonus, improves compilation speeds.
>
> My one question, as I read though the implementation, is "can the core
> benefits of this library be achived with a simpler 'light' version of this
> implementation?". While I appreciate the attempt to encode a Haskell-style
> typeclass hierarchy, I feel like that is not the core competency of hana
> and should be a separate library and discussion. As it is, this is a 32k
> header mega library. I'd prefer several small, highly-targeted,
> highly-composable libraries.
>
>
>>    * Implementation
>>
>
> The code itself looks to be well structured and well documented.
>
> Unfortunately hana only works with one compiler: clang. While I agree that
> Boost shouldn't need to support Visual C++ 6.0 anymore, I believe this is
> going too far in the opposite direction. The home page states that boost
> libraries "are intended to be widely useful, and usable across a broad
> spectrum of applications". I've always interpreted that statement to be in
> a practical rather than theoretical sense and I don't think hana meets that
> criteria. Many other Boost authors have made heroic efforts to meet that
> criteria and the reputation of Boost is due, in no small part, to those
> efforts.
>
> I do appreciate the argument that making use of new features encourages
> compiler implementers to implement then. I maintain, however, that this
> isn't Boost's job. Boost provides high quality libraries that the every-day
> Joe C++ developer can benefit from.
>
> That being my position on the issue, my acceptance vote is conditional on
> hana supporting at least two released versions of mainstream compilers.
> Given that gcc support seems pretty close, that shouldn't be hard to
> achieve.

I have not reviewed Hana yet but I feel the need to comment about any 
arbitrary number of compilers a library must work under. I completely 
disagree with the notion that any such number would be the cause of 
accepting or not accepting a library as part of Boost. If a library is 
found useful and works according to the latest version of the C++ 
standard that should be more than enough for that library to be accepted 
into Boost as part of the review process pending individual reviews.