Re: [boost] [Boost] [Hana] Formal review for Hana

Hi Louis,

...

Some identifiers, whitch defined under boost::hana, begin with single underscore (e.g. `_is_a' in core/is_a.hpp). I think (and be afraid) it will violate [lex.name] p.3 (I referenced n4296) when user use using-directive (i.e. `using namespace boost::hana;'). Rename or move to detail namespace might be better, since thouse are documented as /unspecified-type/. I think you're right. But then it means that the placeholders from Boost.Bind (or even Boost.Lambda if you import them to the global namespace) will also violate [lex.name], right? Still, I'll find a different way to name those. The main interest was that it results in very clear error messages. For example,

fold_left(1, 2, 3); // obviously an error

error: static_assert failed "hana::fold_left(xs, state, f) requires xs to be Foldable" static_assert(_models{}, ^ ~~~~~~~~~~~~~~~~~~~~~~ note: in instantiation of function template specialization 'boost::hana::_fold_left::operator()' requested here fold_left(1, 2, 3); ^ Ah, yes, It is clearer and better, but I think that those symbol names are too generic. So, how about using other namespace like `::boost_hana::tuple` (it seems redundant, though)? e.g. Boost.MPL uses `::mpl_` to implement some details.

The compiler requirements are currently documented in the README, which is the first thing that pops up when you go to the project page on GitHub. You mean [1]? If so, it is not enough what I want. I want something like followings,

-- Hana requires generic lambda, variable templates and ... but not generalized lambda caputure, ... (and so on). It might be tooooo much infos for most of peoples but might help some users and provide guarantee for future releases for who cannot upgrade compiler easier. (Hana requires `shared_timed_mutex`? I believe no.)

Technically, Hana requires the functions that are used inside higher-order algorithms to be pure, but that's about it. In other words, there's nothing in Hana's philosophy that prevents you from modifying the elements of a tuple

auto xs = make_tuple(...); xs[3_c] = "foobar";

However, there is quite a bit of imprecision in the documentation regarding which functions should return a reference and which ones should return copies, so right now it is unclear when the above is actually valid. That will be addressed by this issue [3]. OK, I understand. If the issue affects Hana's design (such as purely, which algorithm can (or not) take a reference and/or can modify within iterating), open a mini-review might be better.

...

* Where is source of documentations? How to generate it? It seems to be generated using doxygen, but any of headers don't contain its documents. The documentation is in the headers. I assume you looked at the online version, though. Comments were stripped from the online version because the library was otherwise too large to upload to Wandbox. If you go look at the source, for example [4], you'll see the Doxygen comments. Ah, that.

[1] https://github.com/ldionne/hana/blob/master/README.md#prerequisites-and-inst... Best, Kohei