Re: [boost] [Boost] [Hana] Announcing Hana's formal review next week (June 10th)

Abel Sinkovics writes:

Hi Louis,

[...]

So if I get it right, a compile-time string class is missing to make it a model of Constant. I know that it can be converted into a const char*, but I think it would be good in the long run to be able to think of strings as values. (as we can do it in runtime code). I guess it can be added in a future version of Hana, when such a compile-time string class becomes available.

Exactly. If I had a compile-time std::string, that would do the trick. Something like std::string_view would be just perfect, I think.

...

[...] But this requires doing the actual work. With tag dispatching, we can just ask whether head_impl<T>, is_empty_impl<T> and tail_impl<T> are defined, and nothing happens until we actually call head_impl<T>::apply(...). This is one of the reasons why I went with tag-dispatching, but frankly this is also a slightly arbitrary decision. Providing customization points is not exactly easy; there are a lot of different solutions. Also, the heterogeneous context definitely makes the task of providing customization points harder, since you can't rely on the actual type of the objects to dispatch.

I understand your point. (I think it might worth an entry in the Rationales section of the doc).

I added a rationale for it. See this issue [1].

The reason why one might prefer enable_if-based overloading is that based on my understanding of the concepts lite proposal, using them one could create a Tuple concept (eg. TupleC<T>()) checking "is_a" and then use it for overloading like

template <TupleC T> auto head(T t);

or even:

auto head(TupleC t);

Which is a nice syntactic sugar for compile-time algorithms and could make type-function overloading more "natural" for C++ programmers. (However, the price for it is probably loosing all the benefits you have explained above).

That's a very interesting idea. However, I think Hana should stick to tag-dispatching for now. In light of C++17 concepts, it might be worth doing a Hana 2.0 anyway, in which case tag dispatching could be reconsidered. Regards, Louis [1]: https://github.com/ldionne/hana/issues/144