Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
On 20/03/2015 19:44, Louis Dionne wrote:
It's essentially the same thing than with MPL/Fusion, except there's a bit more syntactic sugar because of C++14 features. Also, this example showcases how low the syntactic cost of the MPL/Fusion unification is. The only place where we need to bridge between types and values is
using tuple = decltype( hana::unpack(sorted_types, hana::template_<hana::_tuple>) )::type;
which is (IMO) not too cumbersome.
I find it very clear and nice to read (much nicer than the MPL code), except for that final tuple_t to _tuple conversion.
I had to read through the documentation to understand this bit, though I suppose something like a transform with [](auto t) { return make<typename decltype(t)::type>(); } would have worked too?
First, I am glad you find it pleasing to read. Regarding the final tuple_t to _tuple conversion, here is what happens. This is not directed towards you in particular, but to anyone else reading this who haven't read the docs: First, `unpack` is basically the equivalent to `apply` from the Fundamentals TS. It applies a tuple of arguments to a function. For example, given a sequence [x1, ..., xn]: unpack([x1, ..., xn], function) == function(x1, ..., xn) Second, `template_<F>` is a function object whose arguments are Types and which returns a Type. This works well with the intuition that C++ templates are nothing more than functions on types. Hence, template_<_tuple>(type<T1>, ..., type<Tn>) == type<_tuple<T1, ..., Tn>> The final twist is that a type<T> is a nullary metafunction in the MPL sense of the word. Hence, decltype(type<T>)::type is the same as T. In our example, this gives us: decltype(type<_tuple<T1, ..., Tn>>)::type which is the same as _tuple<T1, ..., Tn> Finally, as you suggest, creating the tuple would have been possible with transform(sorted_types, [](auto t) { using T = typename decltype(t)::type; return make<T>(); }); Regards, Louis