ZLS is not an official part of the Zig project
Ah. Zig has a grammar, and the compiler requires a language that implements that grammar.
However, the compiler can also infer - variables, parameter names, etc already, and error handling often involves errors because people haven’t grokked the error system.
The error system, at lower levels of a system, is often explicit and discrete. As we build layer upon layer, from low level library, to middle integration library that abstracts lower levels, we eventually bubble up to the application layer.
At the application layer, we. have a whole stack of underlying dependencies, which to the average person, is totally hidden from view–requirements, errors, everything but the functional endpoints they need to use.
The unique combination of error sets is a total unknown. People, on average, do not know what the possible errors are, where they come from, nor how to handle…typically, on average, at the application layer. And they don’t care, because how can they learn and still be productive?
So while I completely understand the need for explicit error handling, a lack of knowledge at the app layer means a developer is more comfortable letting the compiler handle more. There is just no value in knowing what is going on in the constantly shifting sands of frameworks and very deep dependency trees.
Enter the language server. The language server has perfect knowledge. We can separate the zig language that is required for a person to key from the language that is rendered by an IDE because the LS can fill in the gaps.
To me, this is a very powerful concept…there is no loss of clarity (LS+IDE, or for the explicit gestapo, zig fmt --explicit_err ), and yet compiler errors due to a person miskeying repetitive instruction - explicitly typing what the compiler already knows, a form of matching game “i know what you know, see?” - would evaporate.
The code itself is thinned. The app layer may not care about a bunch of try. Very likely a high degree of the logic is going to be try, big whoop. The app layer may not care about !. Again, don’t know why it could fail, guess it could.
But people do care “hey! This function you called, could return an error, go put ! in the return type!” … it’s like, why do that to people? !void, at the app layer, says “something bad could happen here.”
This is true for just about every statement at the app layer.
In the application layer of a system, failure is everywhere.