Uniform lambda signatures for ygm::container types?

[bwpriest]

Currently, if one has a workflow involving sending visitors to possibly different container types, we need to maintain different versions of the visitor lambdas. For example, a visitor lambda to a ygm::container::map or ygm::container::counting_set must look something like

auto map_visitor = [](std::pair<const key_type, value_type> &kv {
  // do something
})

Meanwhile, a visitor lambda to a ygm::container::array must look like

auto array_visitor = [](const key_type key, value_type &value) {
  // do something
})

And a visitor lambda to a ygm::container::bag, ygm::container::set, or ygm::container::disjoint_set must look like

auto bag_visitor = [](value_type &value) {
  // do something
})

It would be very convenient to have a more uniform signature for these lambdas. For example, it would be convenient to be able to pass the same lambda function to a map, array, or bag of key-value-pairs (see LLNL/saltatlas#25). This particular example could be achieved by changing the array class so that it expects lambdas to be functions of std::pair<const index_type, value_type>, but that might not be the best global solution, especially as we add more container types. Any ideas?

[bwpriest]

Short term I will change ygm::container::array to expect std::pair<index_type, value_type> in its lambdas. We will want a longer-term solution, however.

[bwpriest]

Looks like PR #121 is actually going in the wrong direction because we are unable to replicate the map interface without introducing references that cannot be made truly const. Ergo, I'm going to work in the other direction and make ygm::container::map's lambdas match ygm::container::array. I've glanced over whether we can simultaneously support both interfaces using std::is_invocable and while I believe it should be possible, I haven't yet figured out how to do it.

[bwpriest]

Ok I figured out how to support multiple lambda signatures while still crashing at compile time if a signature is not supported. I'll update ygm::container::map to support the new lambdas while remaining backwards compatible.

[bwpriest]

#123 adds this functionality while remaining (mostly) backwards-compatible. I believe that this issue is now resolved.