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

Subject: Re: [boost] [Hana] Announcing Hana's formal review next week (June 10th)
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-21 11:06:29

Abel Sinkovics <abel <at> elte.hu> 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<Tuple, T>" 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