Functions taking a pointer to an array of pointers get confusing signatures

[Muon]

I've run into an issue with ID3D11DeviceContext::OMSetRenderTargets() where the original takes a pointer to an array of const pointers to ID3D11RenderTargetView, but the Rust version takes an Option<&[Option<ID3D11RenderTargetView>]>. As best as I can tell, it should really just be taking an &[ID3D11RenderTargetView], because it certainly makes no sense to be passing in NULLs in that API. In addition, the current version complicates things by requiring you to move ID3D11RenderTargetView to pass it in. If it took an &[ID3D11RenderTargetView] instead, you could avoid the move by using std::slice::from_ref().

[kennykerr]

The general problem is that the metadata doesn't indicate that the API expects non-null COM interface pointers so it assumes they can all be null, and thus uses Option. We might argue that array parameters should be non-null as any null COM interfaces pointers can simply be omitted. I'm not sure whether that logic is universally applicable, but it sounds reasonable at first glance.

[Muon]

I suppose there are two parts here:

1. The metadata should probably indicate that ID3D11DeviceContext::OMSetRenderTargets() expects an array of non-null pointers.
2. Input-only array parameters should probably be translated as &[T] instead of Option<&[T]>. (The empty slice indicates an empty array.)

[kennykerr]

The metadata should probably indicate that ID3D11DeviceContext::OMSetRenderTargets() expects an array of non-null pointers.

That would be great but an uphill battle that is unlikely to be comprehensive.

Input-only array parameters should probably be translated as &[T] instead of Option<&[T]>. (The empty slice indicates an empty array.)

Yes, that may be possible. I can experiment to see how effective/practical that may be.

[kennykerr]

This looks much like #1339.

[kennykerr]

IDCompositionDevice.CreateTransform3DGroup is another good example as its typically passed an array of derived interfaces.

[Muon]

Unfortunate that #2233 had to be reverted. Currently I have to use OMSetRenderTargets like so:

self.context.OMSetRenderTargets(Some(&[Some(self.render_target_view.clone())]), None)

In addition to it being quite ugly, the signature currently forces an unnecessary clone. It would be strictly easier for me to use without the Options getting in the way:

self.context.OMSetRenderTargets(&self.render_target_view as *mut _, std::ptr::null_mut())

or even

self.context.OMSetRenderTargets(std::slice::from_ref(&self.render_target_view).as_mut_ptr(), std::ptr::null_mut())

[kennykerr]

There may be further options here now that I've dramatically simplified the parameter binding machinery (#2360).