To eliminate confusion with the naming scheme of the newly introduced SourceKit-LSP project compared to the pre-existing Swift/sourcekitd framework, we intend to transition sourcekitd to become the swiftd framework. We believe swiftd is a name that better reflects its functionality, which is providing access to the Swift compiler and no more, while SourceKit-LSP encompasses much more than that.
What this transition means is that in the swift-5.0 release there will be a sourcekitd framework and a swiftd framework alongside it in the toolchain. These frameworks will have identical functionality, but with a slightly modified C API:
The prefix name of the C functions will change sourcekitd_ → swiftd_
There will be a connection object to encompass the global state that is currently implicit in the sourcekitd framework.
The response object will become reference counted.
As you can see we'll take this opportunity to make a couple of improvements to the C API, which we cannot do on sourcekitd since they would break compatibility. However, adopting the new C API should be straightforward.
Both of the frameworks will be in the swift-5.0 toolchain to provide time for third-party tools that are currently using sourcekitd to transition to linking with swiftd. After this release the sourcekitd framework will likely get removed.
Let me know if you have any comments or concerns about this.
Naming nitpick: "swiftd" is a very generic name. Would it be better to pick something more specific like "swift-indexd" or "swift-index-server"? Or, at the risk of suffix overload, "swiftcd", since it's about the compiler?
Could you clarify what you find ambiguous about it, is your concern that it may get confused with another 'swift daemon' ?
I'm not a fan of these, they sound misleading, like it's something that all it does is 'index' your code (in practice this is not even what we'll use the service for).
I'd say it's better that the 'index' variants but it sounds weird, 'swiftd' seems better to me.
Right. "clangd" is "the features of Clang, as a daemon" (let's leave aside whether "daemon" is the right term). "swiftd" sounds like "the features of Swift, as a daemon", but is that Swift-the-compiler / Swift-the-language? Or Swift-the-standard-library-and-runtime? The proposed "swift_" prefix sort of underscores this point: the runtime also contains symbols starting with "swift_".
How about "swiftlangd"? (As in "Swift language daemon", not a pun on Clang. Not directly, anyway.) We don't have any official material that uses "swiftlang" as a term, but it's hardly without precedent.
We already have a 