Analogous to jacobdufault/cquery#247, sending not structured values as params (which is currently allowed here via any type), if present, can upset brittle clients/servers, which are parsing messages literally as per JSON-RPC spec.

Although we use JSON-RPC as a transport layer we decided to limit the params to a single object. This is why on the specification level we ony support a single object. From a spec point of view we should change the property to object. Does that make sense.

I understand that such a limitation might be convenient, however I believe there's a large benefit to retaining the compositional nature of the protocol. It's beneficial to be able to reuse existing JSON-RPC libs and format as is - we could simply add a note, such as 'Array params are technically allowed, but practically unused in LSP' to maintain the compatibility with the JSON-RPC protocol. This would be a win-win, I believe.

We do so in the json-rpc library we use and maintain. It allows to handle arrays correct according to the JSON-RPC spec. Limiting this in the protocol is IMO a fair thing to do and nothing we can change without starting to break since users can implement custom messages. I don't see why we should allow array parameters and then say that they very likely will not work. Implementors of the protocol can still use existing JSON-RPC libs since they will work as design with 0 / 1 parameter.

I realize this is mostly nitpicking, but we should be more consistent here: we can't just say we use and define interface for JSON-RPC messages, yet do otherwise.

Limiting this in the protocol is IMO a fair thing to do and nothing we can change without starting to break since users can implement custom messages.

The thing is, someone could've implemented custom messages passing params as arrays, which is correct under current phrasing that we use JSON-RPC spec, and also currently (in contradiction to previous phrasing) specified any type for params.

If we were to limit legal params type only to object, then we both technically break JSON-RPC compliance and break possible custom messages.

That is why I meant that we could still allow for Array<any> params - this would still leave some leeway for other possible custom messages to still possibly use legal array params as per JSON-RPC spec and would also disallow other illegal params types (e.g. primitives).

You do have a valid point with us claiming that we support JSON-RPC and that custom messages could send arrays. So I would opt to do the following:

• we fix the request / notification definitions.
• we add a clear sentence to the Language Server Protocol section to say that in the protocol itself we only use 0 / 1 param.

@dbaeumer done, I mentioned in the section that object types here are only used, but in general the LSP shouldn't disallow params of Array<any> type.