hana VS xbow

I like boost::hana. Wish I had more chances to use it at work.

And then there's also the longstanding issue with default member initializers -- https://github.com/boostorg/hana/issues/409 -- which was a deal-breaker.The PROP system avoids this issue precisely by having the macro be as local as possible: the default member initializer is outside the macro. It does this while still letting you attach additional PropAttribs metadata (I'm not sure what additional metadata attachment looks like in Hana? haven't really tried). Default values and additional attributes are by and large quite more important to me in my use cases for reflection (component types in game ECS) than range syntax (everything I've needed and can think of needing is covered by for-each loop).

oh yes definitely, but I meant more the particular way I've done it so far - which has been to implement something similar to boost::hana::is_valid(), to make it take the least amount of boilerplate code per-use-case as possible: zero additional lines of code.

Boost.Hana developers measured a very noticeable 15% decrease in compile time switching from a function call (admittedly -- with an additional layer of wrapper) to a raw static_cast. foonathan himself saw a little over a 5% decrease in his actual code. miki151 saw about a 3% improvement from replacing move with MOV only, ignoring forward. In a completely synthetic benchmark where I just generate a ton of move calls in a row, I get a little over 40% decrease in compile time.

An advanced usage example can be seen here. Arrow stores structs in structure of arrays layout, and I use Boost.Hana to do this conversion. My linked code consists of two chained range-v3 views (separated by '|' on line 308).