Jake Hemstad

> I was wondering if there was a way we could pass an argument for this (`do_initialize=true`), rather than use an entirely new class. It wouldn't be very canonical C++...

> With this proposed abstraction, can we use this new feature in .cpp files (instead of requiring nvcc); we're forced to use rmm::device_buffer instead of rmm::device_vector in several places as...

``` fill(data(), size, fill_value); // this function fills [data(), data() + size * fill_value.size()] by repeating fill_value size times ``` I'm confused by your example. What is `fill` if not...

> its implementation can go to .cu file Ah, I see. The goal is to make RMM a header-only library, so that wouldn't work.

Alternatively, we can eliminate the initializing constructor from `device_uvector` all together and make the user initialize it themselves. ``` thrust::device_uvector uv(100); thrust::uninitialized_fill(uv.begin(), uv.end(), 0); ```

> I think this will work much better for cugraph (if this enables us using device_uvector in .cpp files). Is the desire just for reduced compile times by using gcc...

> A bigger gain is that this enables us to define our public C++ API with rmm::device_uvector instead of rmm::device_buffer I'm not quite following this one. Can you explain?

> +1 for ability to use the class in .cpp files. I think that's important. Sure. Just want to make sure that everyone understands that this decision shouldn't be made...

@seunghwak ah, okay, makes sense.

> Does it make sense to add stream support to `thrust::device_vector`, rather than find/make another type? No. The `thrust::device_vector` type is ignorant of CUDA/streams. Furthermore, there are operations that simply...