Replace `mutable` modifier with `readonly`

[sagg0t]

ZLS 0.15 added non-standard mutable modifier for variables which is a great feature.
However for better integration with various tools it's better to use the standard readonly modifier on constants.
It will allow for the same results (logic is just inverted) and will be standard compatible.

Ref: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_semanticTokens

I'd be happy to work on it if the issue gets a green light.

[Techatrix]

It was a deliberate to use mutable over readonly. The reasoning can be found in #2251. If you still think that using readonly is the better choice, you are welcome to present your argument here.

[sagg0t]

Sure. I did my best to understand your arguments in #2251 and ziglang/vscode-zig#213 so I'll refer to your quotes from there.
I tried to address the facts only, so if by any chance you feel like it addresses you personally - it's not my intention and I apologize for it.

TLDR highlighting const vars in Zig is very noisy.

The fact that it makes it look noisy only highlights the fact that the theme highlights constants too aggressively. As you said yourself, "LSP should not decide how to emit semantic token information based on how it affects various editors."
And if some editor/colortheme produces too much highlight - it's a highlight problem, not a semantics problem.

With mutable modifier now it works such that constants in code get variable token type which makes zero sense. So now LSP sacrifices semantics (which is its core feature) in favor of highlight (which is beyond LSP's scope.)
I understand the desire to provide the best user experience, but in this case it looks like a wrong priority over correctness or compatibility.

adding the readonly token modifier would be a bad addition for semantic highlighting in Zig.

As you already know it's a standard modifier. Various tools, not only colorschemes, can rely on standard tokens, not providing it limits options for customization/usage. I can't come up with an example of the tool off the top of my head, but I'm sure you understand the idea.

LSP is a standard for the very reason to provide generic information about language.
Terms like mutable are specific to certain languages and this knowledge should remain within the boundaries of those languages. LSP should be a generalized bridge between a language (with its internals,) and an editor that works with more generic constructs.

rust-anlyzer uses mutable over readonly

For the record I'm not using Rust.
In Rust, syntax implies mutability as a modifier let mut x = 5;. But event then, syntax != semantics since let mut a declares a variable a and let b declares a constant. Even though in Rust's terms they are called differently, that doesn't change what they are. that's why I think it's not the best option even for Rust, but at the very least it mirrors the syntax.

In the case of Zig, there's nothing like that. Even if we use Rust as an argument here, Zig's syntax doesn't have modifiers like that, it uses different keywords. So adopting Rust's model not only goes orthogonal to the standard, but also is a bad fit.

Zig code is usually heavy on const variables.

True, but many expression types, that use const don't produce a constant variable, they often return a type, or a namespace, etc. As for the parameters and captures (which are also parameters IMO) - there's a separate token type for them.
So pretty much the only use case is constants.