To me (a teacher) it means I will finally be able to teach Swift as a programming language on its own, and not just as part of an iOS course. Yes, Windows support is still missing, and that's a big issue, but unlike macOS, Linux is easy to install on any hardware (or a VM), so teaching a complete Swift course on Linux is finally possible.
CLion's next release (currently in early access preview) already ticks most of my boxes, but for non-CS students (or high school), I need something simpler, like VS Code or Atom.
I hope all members of the community are interested in working together on a combined effort. Several people have invested time into solutions in this area.
One of the things that I would like to emphasize is that more of the Swift tooling support in Xcode currently supported by SourceKit will have far more of that core functionality in the open source service (e.g., the global index and global refactoring operations) once we move to an LSP-based implementation. @akyrtzi mentioned this in the original post but that important nuance may been missed. Consequently, the LSP service @akyrtzi is describing will be functionally more powerful than SourceKit is today.
Extremely exciting news for Swift enthusiasts. I have a question more towards Xcode: would it open a door to use Xcode for other languages? For example, Rust is a low level language I find very useful for embedded/IoT. I use some shared code with Rust/Swift & connecting using C ABI.
I also like Xcode and would like to use it to edit Rust. It has its own implementation of LSP (rls). I was wondering if adding support for LSP would make Xcode more open to other languages having LSP implementations.
Getting Xcode to use our new LSP service should make it viable to use other LSP services as well, and it’s something that we are interested in, but we don’t have specific plans to announce at this moment. Our primary focus will be to get the new LSP service integrated and a complete replacement for the existing internal mechanism.
Are there any plans to have the index/cache format description, so it could be used also outside the LSP server if needed?
Do you plan to make extension points allowing to extend the cache/index/LSP functionality without building a custom toolchain (applies to both OSS toolchains and the one bundled in the Xcode)?
Are there any plans to combine the LSP direction with further evolution of Xcode Source Editor extensions and/or making another plugin system allowing to:
a. Add custom UI components in Xcode
b. Use editor API and extend it (not only actions, but also highlighting, completion, etc)
LSP is great to deliver the most of general editor functionality, but next, some tool creators will need to extend it and integrate into existing IDEs and editors - including Xcode. Say, what if one wants to have a semantic highlighting in Xcode when different variables have different colors? He will need to extend the core, next make an extension for LSP protocol, next change how the highlighting behaves in the Xcode, implements custom settings, and for that he needs the ability to extend the UI as well.
We will provide a library usable via a C and Swift API that provides access to the index database.
This is beyond what we are committed in delivering as part of this announcement. I'd recommend to make your enhancement requests known to the Xcode team via https://bugreport.apple.com, if you haven't already.