So the `constexpr` traits do not really look better here. But
they may be better for writing linear code in complex trait
processing, as opposed to complicated recursive code. Still
to be determined. However, If I stay with this and if
`std::find_if` and friends are `constexpr`, then the `Mata`
algorithms can be removed, and `std::` forms will just work.
That's a nice bonus.
Otherwise, we need something more like `boost::mpl`, which is
kinda annoying. Still, `Meta::Container::vector` is very
nice -- it side-steps some issues with using `std::tuple` as
a type-list.
It's a lot of heavy lifting. I'm not sure it actually
adds any useful value yet, but I'll continue to play
with it. It is nice that we can *sometimes* use
loops. Sometimes we can't though. And we have
to make some blind-corner evaluations that throw
dummy failures to keep the compiler from complaining
about missing cases -- despite the fact that they;ll
never be reached at compiletime. (Runtime evaluation
could be different, of course.)
I think, perhaps, a universal representation of a
dereferenced iterator might solve some of this, but
I also don't want to sink too much effort into this,
despite how much fun I'm having.
I'm still on the fence about going full `constexpr` functions
for meta-code. Overall, I think there's potential here. I'm
not aiming to replicate what `boost::mpl` or `boost::hana` do
though. This is more of an internal support mechanism for
Alepha code. As-needed I'll implement things.
When using `enable_if` clauses in templates, we need an NTTP
in the mix to let us get good overloading support. The boolean
true/false trick of the `enable_if` second parameter actually
doesn't work for many situations.
This one is going to be prepped for GitHub private, from the get
go. This initial commit has some evaluation helpers and the
unit testing infrastructure. `TableTest` will come next.
