In pretty much any practical circumstance, whenusing `ListAll` or
`ListAny`, you have a list of types on which you run some sort of
predicate on each item in the list to determine whether any or all of
the items match the predicate. To make this easier, add a second
argument to `ListAll` and `ListAny` to provide a predicate that will
automatically be added.
If no predicate is given, then the operation is run directly on the
list. This is implemented by just using an identity operation.
These new features to VTK-m lists allow you to compute a single value
from a list. `ListReduce` allows you to compute a value based on a
predicate. `ListAll` and `ListAny` use this feature to determine if all
or any of a list of `true_type` or `false_type` objects are true.
The previous implementation of `ListAt` would iteratively pass through
the list to find the i'th entry. It was made faster by searching through
8 indices at a time, but it could still be time consuming for long
lists.
This change instead uses a divide-and-conquer approach. It does this by
first creating a `vtkm::List` with i repetitions of `const void*`. It
can do this by recursively splitting i in half and appending the
resulting lists together.
It then uses this list of `const void*` by constructing a method that
first takes these i `const void*` arguments, then a pointer, then
whatever. The method returns the type of that pointer. The method is
never actually defined, but a `declspec` can determine what the return
type should be.
This method was taken from brigand
(https://github.com/edouarda/brigand).
`vtkm::List` is meant to replace `vtkm::ListTag`. Rather than
subclassing a base class with a variadic template, all lists expose the
list of types.
`vtkm::ListTag` was originally created before we required C++11 so
supporting variadic templates was problematic. To hide the issue we had,
we made list tags subclass other lists rather than be the list
themselves. It makes for nicer types in the compiler, but hides
important details about what is actually in the type. It also creates
lots of unnecessary new types.
The new `vtkm::List` is in some ways simpler. All lists have to be a
`vtkm::List`. Subclasses are not supported (or rather, they will not
work as expected). All manipulations (such as `vtkm::ListAppend`)
resolve directly back to a `vtkm::List`. Although the types reported by
the compiler will be longer, they will be more specific to the types
being used. Also, the new implimentation should ultimately use fewer
types.
