> std::variant. The high compile times stem simply from the fact we have
> to cycle through the Cartesian product of the set of types of each
I absolutely agree on that diagnosis, but I think std::variant can play a role. The key
is to postpone dispatch, where possible, to refactor out one or more of the product
terms.
At the moment the dispatch mechanism identifies all the concrete types first, then
runs the correct instantiated function. If there were more flexibility in this process,
dispatching to selected type-dependent code could happen later and cover less code.
Consider:
template<class A, class B, class C>
void foo(A a, B b, C c)
{
// lots of A and B code
// a single use of C
// lots more A and B
}
For the sake of a small amount of code involving C the entire function gets rebuilt as
many times as there are C types. Now consider an approach that postponed
determining C's concrete type:
template<class A, class B>
void foo(A a, B b, std::variant<C1, C2, ...> c_var)
{
// lots of A and B
std::visit([](auto const & c){ // use of C }, c_var);
// lots more A and B
}
If C was something based on scalar_types this would mean a factor of 6 reduction in
instantiations!
It's true that you could do the same trick - though IMO less cleanly - with boost::any and
a typelist. But this would leave off the other advantage of variant: constant time dispatch.
I don't know what the runtime impact of the current iterative approach is, but it seems like
it could particularly important in filtered graphs, or in algorithms with a lot of callbacks
(like my personal favorite, astar_search).