3 ms·
Just to clear what seems to be some confusion in what you wrote: Clangd already exists (it was contributed and mainly maintained by Google, IIRC), and works gr
by DannyBee 9y ago
Just to clear what seems to be some confusion in what you wrote:
Clangd already exists (it was contributed and mainly maintained by Google, IIRC), and works great. It supports LSP, and works fine with vscode.
What apple is investing in is making it their default tooling.
So the benefits of this change are exclusive to apple xcode (ATM) :)
The benefits to using clangd in general are (among poher things) editor agnosticism and scaling.
If everyone uses libclang, libclang must scale to every codebase (or a least, the interface, and then you'd have to replace/relink it).
If everyone uses LSP, you just need something that speaks LSP, and scales to your codebase.
At the scale of Google's codebases, for example, the first is untenable, the second is doable.
- kenferry 9y agoWell, I mean, it's a little more than that unless clangd is straight up finished software. Apple will now be contributing to clangd as well, which benefits all clients of clangd.
- DannyBee 9y agoThat is why I said "at the moment". It also depends heavily on what extensions are contributed and how and whether they are standardized, etc. Certainly missing LSP functionality helps everyone, but the rest depends quite a lot on approach and details.