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.