I believe this is correct (and ABI-contractual) behavior for Swift metatype values: because there is only one possible value of PHLivePhotoBadgeOptions.Type, the representation is empty. You can use Any.Type if you want a general runtime value.

cc @rjmccall, @jckarter

Yeah, this is correct behavior. What do you mean by "outside a Swift environment"? Your other example writing to `UnsafeMutablePointer<X.Type>` is also a no-op, because X.Type has only one value so is an empty type. (Nevermind, the Pointer types always point at the maximally abstracted representation, which will give you the metadata pointer value in memory.)

It's okay for a function returning a concrete metatype to understand that the type is trivial and avoid actually doing the work to create the metadata object. The store will work because `UnsafePointer` always stores the most general representation for its type argument, but the more efficient way would be to make the function return a non-concrete type, e.g. by returning `Any.Type`.

Comment by Steve Hawley (JIRA)

I disagree. A function declared to return a value needs to return a value. The implementation as is leaves the return register untouched, which means its garbage. Even if there is only one possible value of `PHLivePhotoBadeOptions.Type`, it should return it. I don't see how Any.Type would be a valid substitute for the type metadata for that.

With regards to the work around code, it doesn't look like a no-op to me in the disassembly.

Why do I need this? I'm calling swift code from a C environment and in other code, I need to pass the type metadata back into swift for generic functions (example, construct Swift.Array<T>) as well as to root around in it to get size, stride, etc.

Can you explain in more detail why the singleton nature of type metadata would prevent a function that is declared as returning it from returning it?

You don't actually get to disagree here. You're trying to write C code that matches the Swift ABI, which means you need to do what the Swift ABI does, not what you would find it convenient if the Swift ABI did. If you'd like to work on a compiler feature that makes it easier to match the Swift ABI, e.g. by outputting a C header suitable for use by Clang that declares the public interface of a Swift module in all of its wildly-attributed and name-mangled glory, I think that would be really interesting.

Alternatively, if you want Swift functions to be usable from C, use the @_cdecl attribute to export them as C functions, using the C calling convention:

// Swift
@_cdecl("foo") func foo(x: Int) -> Int { ... }

// C
intptr_t foo(intptr_t);

You won't be able to directly use Swift-only types without an analog in C, such as metatypes, but you can control the marshalling to C by converting to types that do exist in C.