In Plan for module stability I outlined what we're looking to do in the coming releases in the form of "textual interfaces". @harlanhaskins and I have already made some good progress on this, and you can see the files (though not really use them for anything yet) in the downloadable toolchains as of this week. But we do need to pick proper names for these things, and in particular the command-line flag that instructs
swiftc to emit one. (Right now it's
Driver flags for top-level outputs are usually in the form
-emit-objc-header-path. There are also sometimes forms without the
-path suffix, which mean "emit one of these, but derive the path from the main output". So the main decision here is what to use for the "FOOBAR" portion of the pattern.
I haven't been too consistent on terminology so far within the compiler implementation. So far I've used:
- "swiftinterface" as the file extension, and sort of a name for the format
- "ModuleInterface" for the test directory and a handful of functions in the Frontend library
- "TextualInterface" in other parts of the compiler, where "ModuleInterface" sometimes refers to the "pretty" interface generated by SourceKit (the one you can see in Xcode)
I'd like to be consistent here, and I'd like the name used by the driver option to be something that generally makes sense. "Module" is already heavily overloaded, and I probably shouldn't be responsible for doing the same thing to "interface". (I'm not hugely attached to that noun either if someone thinks of something better.)
I'll also note that "textual" only makes sense in contrast to the existing binary format. "Stable" is a bit better, but might raise more questions ("does that mean something else is unstable?").
Early candidates for the flag: