On Tue, May 20, 2014 at 3:53 PM, Louis Dionne <ldionne.2@gmail.com> wrote:
Lee Clagett <forum <at> leeclagett.com> writes:
With Boost.Hana, that would actually be
template <bool IsOrdered> struct Values { static constexpr auto values_t = if_(bool_<IsOrdered>, type<std::set<int>>, type<std::unordered_set<int>> ); typename decltype(values_t)::type values; };
which is worse than the current MPL. However, perhaps sticking to simple tools is better for simple problems:
template <bool IsOrdered> struct Values { using values_t = std::conditional_t<IsOrdered, std::set<int>, std::unordered_set<int> >; values_t values; };
I'll admit that I would like these simple problems to have a simple solution in Boost.Hana. It might be possible by providing thin wrappers for type-only computations; I'll evaluate that and provide feedback.
That syntax isn't so bad, maybe its just a matter of getting used to a different style. The unfortunate part are the type<> wrappers. Larger expressions could look unsightly.
That seems like a step backward to me. It is possible to "stitch" together the runtime and compile languages with the expanded "using" keyword, but is
I'm sorry, but I don't see how the "using" keyword helps at all here. Could you please expand?
Type aliasing can be combined with type introspection (decltype) to get an existing MPL style: template<bool Conditional, typename Then, typename Else> using if_d = typename std::result_of< boost::hana::_if( boost::hana::Bool<Conditional>, boost::hana::Type<Then>, boost::hana::Type<Else>)>::type; template<bool Ordered> using map_type_t = typename if_d<Ordered, std::set<int>, std::unordered_set<int>>::type; static_assert( std::is_same<map_type_t<true>, std::set<int>>::value, "expected ordered"); static_assert( std::is_same<map_type_t<false>, std::unordered_set<int>>::value, "expected unordered"); I used result_of instead of decltype directly, it looks a little nicer I think. The syntax would even work with MPL value computations like count_if, assuming a Integral<0> could be used as the initial value (I think it can in the hana design). The trick is returning an integral<> in that situation, otherwise decltype isn't computing a useful value. The only place I know this gets complicated is with lambda expressions, not sure how that would be merged. Lee