Kohei Takahashi
[...] The main interest was that it results in very clear error messages. For example, [...] 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.
We could use `::hana_`, or simply use `boost::hana::fold_left_t`. I'll think of something.
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). [...]
I understand what you want. I added more specific requirements.
[...] 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.
No, the issue is not Hana's design, but rather the current implementation. [snip] Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Hana-Formal-review-for-Hana-tp46769... Sent from the Boost - Dev mailing list archive at Nabble.com.