[boost] Boost Hana comments

Subject: [boost] Boost Hana comments
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2014-08-13 14:28:41

First off, while I haven't thoroughly reviewed the library, I am certainly
impressed by a lot of what I see.  It is obvious that this library
represents a lot of excellent work.

Here are my miscellaneous comments:

Constant type class:
--------------------

Why isn't std::integral_constant an instance?

There is no documentation of what the value method actually returns, just
that it returns something that is a constexpr.  Does value(integral<int,3>))
return int, or does it return integral<int,3> ?

Perhaps the Constant type class should be "parameterized" by a type
specifying the return type of value.

Integral data type:
-------------------

It would be better not to duplicate std::integral_constant.  However, I
recognize that the overloaded operators are useful and you wouldn't be able
to do this with std::integral_constant (well, I suppose you still could, but
as they wouldn't be found by ADL, they wouldn't be terribly useful).  This
rationale (assuming it is correct) should be documented though.

Logical type class:
-------------------

What is really gained by making this a type class at all?

It seems that and_ and or_ require that all arguments be of the same "hana
datatype", though actually this isn't documented anywhere and this might not
even be the precise requirement (but obviously it needs to be documented
very explicitly, and this probably applies to almost every method in Hana).

Really we really should be able to mix multiple data types in a call to or_
or and_, though.  Otherwise the usability is unreasonably limited.  Of
course there is then the question of return type.  However, I would assume
most users would be happy getting back either a Hana Integral or a bool,
depending on whether it is a compile-time or runtime condition.  Certainly
this would be better than getting back a compiler error.

Another question: how does the performance of and_ and or_ compare to the
optimized verions you showed in your MPL11 talk?

Pair datatype:
--------------

Why duplicate std::pair?  Alternatively, why duplicate list?

Perhaps list should just define first and second as well?

Product type class:
----------------

Why isn't a 2-element List, a 2-element std::tuple, etc. an instance?

List type class:
----------------

Just as for Logical, it would be useful to be able to mix datatypes in calls
to concat, zip, zip_with.

The list function itself shouldn't be documented as part of the type class,
since it isn't logically part of  it.

What about get<N>, get<N,M> accessors?  I understand these can be defined in
terms of the other methods, but clearly they are useful on their own.