Pitch: A vision for COM Interoperability in Swift

[compnerd (Saleem Abdulrasool)]

@John_McCall

Vision documents are, as much as anything else, opportunities to create a common basis of communication for all the design conversations to come. To do that effectively, they generally need to explain the problem to a reasonable level of technical detail. So it would be good to see a more thorough explanation of what COM actually is here.

I can try to integrate some of this into the vision document itself. I'm basically taking the position that COM is the ABI - IUnknown + ABI vtable layout/function thunks as a dual view of a type.

@John_McCall

I also don't think it would be inappropriate for the vision to be more concrete about what you expect Swift COM code to look like, especially when the choice seems almost forced. For example, COM objects would always be instances of Swift classes, right? And COM interfaces/protocols would be class-constrained as well.

Correct on both counts. I thought I put that into the document, but there is no way around the AnyObject requirement as the types must be reference counted.

@John_McCall

Idiomatically, I think COM classes generally have to know about all the interfaces they implement in order to correctly implement QueryInterface. Are you imagining that we would restrict retroactive conformance for COM classes, or are you imagining a different implementation that does some kind of dynamic lookup like Swift conformance lookup does?

I was thinking that we could close retroactive conformances for COM protocols, but leave it open for Swift protocols. This is required since we need to maintain identity and the layout of the vtable requires complete information.

@John_McCall

Similarly, in the safety section, you talk about types like BSTR and HSTRING being safely imported. These seem to be unmanaged pointer types in C++.

BSTR is not reference counted and would need a type wrapper. It must be allocated from a different heap via SysAllocString and released via SysFreeString.

HSTRING is reference counted (WindowsCreateString, WindowsDuplicateString, WindowsDeleteString manage the refcount, and WindowsCreateStringReference lets you create uncounted strings - views to statically backed memory).

@John_McCall

One last question for now: should it be a goal that COM interop doesn't impose significant performance burdens on non-COM code?

Yes, I think that this is a desired part of the design as well. Unless you

• enable COM interop, it should have no material impact (we will need a couple of minor changes to the runtime adding a couple of small entry points which everyone will pay for)
• use COM interop, should have no real impact and even then would be limited mostly to additional metadata and an additional runtime library
• should not impact interoperability of modules built without COM interop

[John_McCall]

@compnerd

I can try to integrate some of this into the vision document itself. I'm basically taking the position that COM is the ABI - IUnknown + ABI vtable layout/function thunks as a dual view of a type.

Right, I think that’s basically the level at which it needs to be explained: the operations on IUnknown, the query concept, any standard conventions, and the rules on object management.

[ksluder (Kyle Sluder)]

Part of that description should probably be how this interop layer plans to handle COM aggregate objects.

• Will as? casts invoke the QueryInterface() of the static type? In other words, is let my obj: any IUnknown = IMyObject(); myObj as? ISomeInterface going to call IUnknown::QueryInterface() or IMyObject::QueryInterface()?
• How does a COM object authored in Swift correctly implement a COM interface by delegating to another object it owns that already implements that interface? Does the Swift version of the object have to manually forward all methods to the subobject, and is that even a valid way to do COM aggregation?