or.hpp regarding forwarding of x twice into hana::if_. It seems impossible unless you put the same logic that is in eval_if to convert x to bool or an IntegralConstant that contains bool.
hana::optional<T> or does one have to use decltype(hana::just(std::declval<T>())? (the doc says "implementation defined" but I'm not sure to what extent)
hana::map< implementation_defined > but for optional it is hana::optional<...> which makes me think it might be okay.
nothing’s type is optional<>, and just(x)’s type is optional<T>.
hana::optional<T> and hana::optional<> directly is okay?
I'm not sure if what I am doing is a good idea yet, but I decided to not bother wrapping tuple and just represent a message as a tuple where some 'fields' like a payload might not be present.
BOOST_HANA_CONSTANT_ASSERT(
builder::entityMessages(entity_map, access_point)
==
hana::make_tuple(
hana::type_c<hana::tuple<
hana::optional<>,
channel::Upstream,
action::Create,
path_type,
hana::optional<entity::E1>,
hana::optional<>
>>,
hana::type_c<hana::tuple<
hana::optional<bool>,
channel::Downstream,
action::Create,
path_type,
hana::optional<entity::E1>,
hana::optional<>
>>,
)
);There is also this, but after a second look maybe I should have used value_or :P
https://github.com/ricejasonf/nbdl/blob/develop/src/mpdef/CollectSettings.hpp#L25
In any case it's nbd. I'll just avoid using it that way if it remains 'implementation_defined'.
value_or because I wanted that map lookup to be lazy
mpdef::make_map.
mpdef::Map registered at .5s for 200 lookups.
Your new post made me think of your todo in or.hpp regarding forwarding of x twice into hana::if_. It seems impossible unless you put the same logic that is in eval_if to convert x to bool or an IntegralConstant that contains bool.
That is correct, at least I think so. But I can't do that without losing the generality of or_'s current definition, because someone could define a new Logical that's not a bool or a boolean IntegralConstant. But even disregarding this issue, I feel like the Logical concept might be flawed. I tried to be very general, but it gives something that provides bad compile-time performance for such basic operations. I would perhaps make more sense to only define these operations on boolean IntegralConstants. We would lose the ability to branch on runtime values too, but the rest of the library does not support runtime conditions anymore anyways.
I didn't compare the benchmark against your version of the hash_map but the mpdef::Map registered at .5s for 200 lookups.
Care to send me the benchmark? Or did you already do it previously and I just forgot? I remember you showing me this graph before.
hana::map is one deep freaking mystery. We made it better, but still not as good as we need for the most common use cases (types only or similar simple things).
optional, I’m thinking about it. The thing is that constructors are documented, so it would seem to make sense that the type part of the API too (otherwise how do you call the constructor?).
mpdef stuff my biggest speedup was using an empty list instead of hana::tuple. It is almost exactly like hana:types only it doesn't wrap its members in hana::type.
hana::type when it returns them from e.g. at?
unpack yes
hana::tuple has to have a bit of complexity to have an interface not too far from std::tuple.
hana::tuple is overload resolution on the constructors.
hana::experimental::types?
hana::type would cause a significant compile-time hit, really.
detail::hash_table... maybe I should be using metafunctions
optional, I opened boostorg/hana#254 so I don’t forget it.