Gonzalo Brito Gadeschi
This approach has advantages/disadvantages, the ones that come to mind are: - i think it only works if the types in the tuple have constexpr constructors (_huge drawback_ unless a workaround is found),
I think it won't work with incomplete types, with types that don't have a default constructor and with function types too. There might be a good workaround for this though.
- performance (it might be slower to compile, but I haven't profiled so I don't know),
If it turns out to be an interesting avenue, I'll benchmark it properly.
- it gives you a unified way of performing type-only and type-value manipulations at compile-time,
Definitely a plus.
- you cannot use lambda functions inside relaxed-constexpr functions (so the restricted part of C++ that is allowed inside constexpr functions needs to be considered).
Another thing with constexpr functions is that you can't static_assert on their arguments, but I don't think that would be a show stopper.
If so, Boost.MPL and Boost.Fusion would have some overlap that might be worth studying.
I do think these libraries overlap. Actually, I think Fusion would be pretty much a superset of the MPL if it was not for the fact that Fusion must work with types that can be constructed. Could someone involved with Fusion confirm or refute this? Regards, Louis