On one hand it's really nice to see Apple jump on the LSP train and use standard tooling for their IDE to interact with language tools.
On the other hand, instead of having a consistent strategy of using proper LSP (which by specification is JSONRPC), they are shoehorning LSP on top of their in-house XPC transport. To do that they're planning to introduce additional complexity to clangd (a transport abstraction), while actually defeating one of the main purposes of LSP, which is reducing the m-times-n complexity problem of matching compilers with tools to an m-plus-n complexity problem. No other tools (unless they support LSP-over-XPC as well) will be able to talk to XCode. XCode won't be able to talk to other tools. I hope they rethink that decision, keep clangd simple and instead adopt proper (JSONRPC) LSP in all of their other tools for Swift, etc instead. That way they'd not only open up XCode to clangd, but also all other editors to their refactoring tools for Swift, etc.
On one hand it's really nice to see Apple jump on the LSP train and use standard tooling for their IDE to interact with language tools.
On the other hand, instead of having a consistent strategy of using proper LSP (which by specification is JSONRPC), they are shoehorning LSP on top of their in-house XPC transport. To do that they're planning to introduce additional complexity to clangd (a transport abstraction), while actually defeating one of the main purposes of LSP, which is reducing the m-times-n complexity problem of matching compilers with tools to an m-plus-n complexity problem. No other tools (unless they support LSP-over-XPC as well) will be able to talk to XCode. XCode won't be able to talk to other tools. I hope they rethink that decision, keep clangd simple and instead adopt proper (JSONRPC) LSP in all of their other tools for Swift, etc instead. That way they'd not only open up XCode to clangd, but also all other editors to their refactoring tools for Swift, etc.