Should nccl::broadcast take a Option<&T> instead of an &Option<T>?

[dkales]

In

cudarc/src/nccl/safe.rs

Lines 242 to 245 in 886d6d2

	pub fn broadcast<S: DevicePtr<T>, R: DevicePtrMut<T>, T: NcclType>(
	&self,
	sendbuff: &Option<S>,
	recvbuff: &mut R,

, the sendbuf is given as an &Option<T>, which involves wrapping the T, which is something like a CudaSlice in an Option to pass it in there, making re-use of the sendbuffer later on less ergonomic, since you need to get it back from the Option. The other way around would make this easier, but IDK if there are some other drawbacks I'm not seeing ATM?

[coreylowman]

Hmm yeah actually I agree with you. At first I thought Option provided a way to do this, but its the reverse - Option::as_ref "Converts from &Option<T> to Option<&T>."

[coreylowman]

I think using the CudaViews is a fairly okay work around for this (probably why it's usable in the first place). Creating a view is very cheap and you can reuse them as many times as you want. Unless I'm missing something.

[dkales]

I think using the CudaViews is a fairly okay work around for this (probably why it's usable in the first place). Creating a view is very cheap and you can reuse them as many times as you want. Unless I'm missing something.

yeah this is a workaround, but only possible since the last version while this interface was there much longer, just wanted to raise this as a suggestion