I'm late the party, but this thread was referenced in response to a question I had a couple days ago.
I want to build a Swift wrapper for SDL, an open-source graphics/event-handling library. At one extreme, it would make sense to write a comprehensive apinotes file for it and package it as a module (if only I could find comprehensive docs on how to do that). But that doesn't make it very Swifty, particularly in that you don't get ARC support.
So the next thing would be to wrap the API in a set of Swift classes and structs. I started to do this with SDL, and used the systemLibrary() in the SwiftPM to import the C API. I got stuck because there’s a set of #defines in the C API that I wanted to use early on to prove things out, but they weren’t visible to clients of my SwiftSDL module (I haven't yet tried @_export).
In the long run, this should be an OptionSet anyway, and I built that shim manually, but I feel like this is what I should be able to do (for example): Use apinotes to convert an enum to an OptionSet, and re-export just that OptionSet. Since I don’t control the C API, I need to be able to apply the apinotes as part of my library (SwiftSDL), which should allow the compiler to handle the fine-grained re-export.
Also, I don't like language of public import Foo. “Import” means one thing, “export” means the other, so I’d rather see import Foo; export Foo. But it’s a bit strange to export the imported library at the source file level. What happens when I have several source files? Any one of them could trigger the re-export. Seems like this should exist in a more central file for the module (e.g. Package dscriptor or apinotes or modulemap).