Bikeshedding for a new Driver flag: -emit-interface-path?

Development Compiler
1

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 -experimental-emit-interface-path.)

Driver flags for top-level outputs are usually in the form -emit-FOOBAR-path, like -emit-module-path or -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:

  • -emit-interface-path
  • -emit-module-interface-path
  • ?

cc @Graydon_Hoare

2

:-1: unless you plan to push heavily for this feature to be called "Interfaces" with no extra qualifiers, please don't choose this.

:+1: module interface is specific enough for me.

It's unfortunate that -emit-module-path has the simpler name, but I don't know what we can do about that without breaking compatibility of the driver. Do you think it would be worth trying to slowly move (add new alias, deprecate, eventually remove) to a different flag name for the unstable binary module interface to avoid this confusion?

1 Like
3

Iā€™m fine with -emit-interface-path.

4

The problem with "module interface" is that we're already (internally) using that term for what Xcode calls the "Generated Interface" of a file or module. That's a similar AST-printed format, but not close enough that we'd share implementations or use cases or anything.

5

Fair enough. I'm less worried about internal terminology though. I always call it the "generated interface" or "swift generated module interface" when I talk about it anyway.

1 Like
6

Related:

https://github.com/apple/swift/pull/19713

I still haven't decided if I like that as the driver flag, though.