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

Subject: Re: [boost] [Hana] Formal review for Hana
From: Kohei Takahashi (flast_at_[hidden])
Date: 2015-06-21 12:22:28

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<Foldable, S>{},
>                 ^             ~~~~~~~~~~~~~~~~~~~~~~
>     note: in instantiation of function template specialization
>         'boost::hana::_fold_left::operator()<int, int, int>' 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-installation

Best,
Kohei