Metal: Reexpose safe wrappers for static MTLDevice getters

[MarijnS95]

The safe wrappers for these static functions seem to have been commented out as it is really hard to extend a dynamic trait object with some concrete static functions (that exist regardless of a concrete type implementing the MTLDevice trait). Instead, make them available as free functions prefixed with mtl_device_*(), to allow users to more easily read the "system default" device or get a list of all devices.

[madsmtm]

Thanks! We should work on fixing this in the generator itself, instead of fixing it locally like this, but for now I'm fine with fixing this locally for Metal.

[madsmtm]

I would rather have these be something like:

pub extern "C" fn MTLCreateSystemDefaultDevice() -> Option<Retained<ProtocolObject<dyn MTLDevice>>> {
    extern "C" {
        pub fn MTLCreateSystemDefaultDevice() -> *mut ProtocolObject<dyn MTLDevice>;
    }
    unsafe { Retained::from_raw(MTLCreateSystemDefaultDevice()) }
}

That is, change the signature of MTLCreateSystemDefaultDevice to do the Retained::from_raw step internally.

[MarijnS95]

That would be lovely! I take it from this that we should keep the name to match Objective-C with CamelCase too?

Let me know when you can set that up in the generator, which would save us the hassle of reimplementing. But if you don't get to that in time, landing this now should make it easier to notice that there's some files that can be removed in the future.

[madsmtm]

Hmm, I've been (and will be) away for various summer holiday activities in recent times, so I'm a bit out of the loop myself. I think it would be fairly easy to implement generally, but I probably won't have time to do it before August.

I'm fine with pulling this change now, but in any case, I'm probably not going to cut a new release before it's implemented generally (opened #639), so you could also just wait for that.

[MarijnS95]

I don't absolutely need these functions right now (would be nice to start using them in the example in Traverse-Research/gpu-allocator#225).

Shall I leave this PR open then to not forget to remove this custom file when you've resolved #639? Thanks in advance!

[madsmtm]

I don't want to expose this, users should use Retained::from_raw(ptr.as_ptr()).unwrap() instead as the unwrap should be optimized away (and if it isn't, we have Option::unwrap_unchecked for that).

[MarijnS95]

Hmm that seems a bit silly when there is an API primitive available that is nicer and easier to read?

from_raw() uses this under the hood after all, and the only difference I see is the extra + Message bound to get access to it.

[madsmtm]

Agree that it is a bit silly; but I'm trying to follow std here, and the prime examples of smart pointers, Box and Arc, only expose Box::from_raw and Arc::from_raw, and I don't really want to differ from these here if I can avoid it.

[MarijnS95]

I hadn't thought about matching std at all, where I don't use these functions very often (they're after all only to for raw pointers that originate from Rust at some point, i.e. temporarily creating a "user pointer" for FFI).

Here in objc2 it seems to make sense given that your bindings already generate a NonNull annotation where applicable.