Really nice work here — the parser especially. The Index type is a good call: making the initializer failable so a raw 0 (the reserved null) can’t produce a value means a non-optional Index is itself proof the row exists, and CodedIndex composing on top of it keeps the tag/table dimension type-safe too. That’s the right instinct for a format this full of indices.
I’ve spent a fair bit of time in this same area, so a few notes that might be useful — some of it is recent enough that you may not have seen it yet.
There’s active work toward first-class COM interop in Swift: a @COM attribute where the compiler handles the vtable layout, QueryInterface as as?, AddRef/Release via ARC, and HRESULT → throws — so a COM interface becomes just a @COM protocol, with no annotated-C++-header layer in between. Some of the compiler pieces are already landing behind an experimental flag, and there’s a vision pitch up for it with the two companion design docs linked, if you’d like to dig in: Pitch: A vision for COM Interoperability in Swift
Two things that follow from how it’s structured:
-
The C surface is elevated through the Clang importer (HRESULT →
throws, property synthesis, name translation, MIDL array handling), with APINotes supplying accurate SDK types — rather than generated headers, and not gated on any new language feature. -
WinRT is a pure-library layer on top of the COM foundation — explicitly no compiler changes — so it largely follows once the core lands.
I mention it because a couple of the next steps you described — working out how the generated C/C++/Swift interact, and leaning on Clang attributes for the projection — overlap heavily with what this design takes on directly. Once a COM interface is just a @COM protocol, much of that annotated-header middle layer falls away, which may save you the trickiest part of what you’ve scoped.
For full transparency on where I’m coming from: the existing BCNY projection is built on earlier work of mine, and my plan for it is to move onto the @COM support plus swift-winmd. I’m sharing that so you can see the direction I’m working in, not to tell you where yours should go.
The piece of your work I’d genuinely encourage you to push on is the NuGet handling. Completed and landed in SwiftPM, it would meaningfully improve NuGet support for system packages — valuable well beyond this projection, and independent of the COM work. The per-SDK packaging quirks are real, reusable infrastructure, and I’d be glad to see you own that. It’s something I’d like to see happen, so if you take it on I’m happy to be a sounding board.