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::mapis 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?).
hana::typewould cause a significant compile-time hit, really.
hana::decltype_strips references is because it couldn’t be implemented consistently when keeping references. So it was decided that stripping references completely, while arbitrary and limiting, was the simplest choice.
constbecause it’s a
hana::decltype_since it’s a temporary, and it’s then transformed into
optional<>after removing rvalue reference.
hashis simply discard the cv-qualifiers of the value in the
IntegralConstant, for the cv-qualifier does not change whether two
IntegralConstants are equal.