ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
hana::at_key(result, MemberName{})
auto& member = boost::hana::at_key(result, mp_at_c<decltype(member_name_var), I>);
I
being the index
using MemberName =
the error will be more obvious
value
?
hana::string<'t', 'i', 'm', 'e', 'r'>{}
at_key
find
which returns an optional
hence the weird error
my::not_found
std::visit
hana::overload_linearly
and give a lambda that takes a my::not_found
as its parameter and then a generic lambda that handles the compile-time string
mp_rename
shuffles the types from the variant to a hana::tuple, but I think I still need to wrap them in a hana::type_c. Which I struggling to do. This is easy to do for boost::variant but there isn't matching support for std::variant that I can see
hana::experimental::types
does the same thing without wrapping individuals types in type
as that tends to create a lot of unnecessary type instantiations. If all you are doing is type computations then you don't want to use hana::tuple
either as that has several member templates that are expensive to instantiate (relatively).
mp_transform<hana::type, mp_rename<Var, hana::tuple>>>