Would it make sense to add a variadic overload of make_zip_iterator that composes the existing make_zip_iterator with make_tuple? I have this in my own code, and I find that it reduces syntactic overhead.

template<typename... Iterators>
__host__ __device__
  zip_iterator<thrust::tuple<Iterators...>> make_zip_iterator(thrust::tuple<Iterators...> t)
{
    return zip_iterator<thrust::tupl

Report needed documentation

We do not have documentation specifying the different treelite Operator values that FIL supports. (https://github.com/dmlc/treelite/blob/46c8390aed4491ea97a017d447f921efef9f03ef/include/treelite/base.h#L40)

Report needed documentation
https://github.com/rapidsai/cuml/blob/branch-0.15/cpp/test/sg/fil_test.cu
There are multiple places in the fil_test.cu file

I would like to be able to determine my device-wide primitive's temp_storage_bytes before I have all of the primitive's arguments ready. The interface for obtaining it ostensibly requires everything to be ready for the actual run - and the documentation does not make it clear what arguments it actually needs and what it's going to do with them (e.g. will it look at the input at all, in any way? Pr