LSP messaging does not properly handle trailing `.0` on integer values about lsp HOT 7 CLOSED

JSONRPC spec says:

id
An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2]

It doesn't say "MUST NOT" but still.

from lsp.

They are specified as JSON, and JSON does not have the concept of integers, only numbers

In JSON, there is no difference between 1 and 1.0.

The entire protocol is in JSON. What is there to argue here?

I'm not going to debate with you guys anymore on this bug as it seems like you guys are not open to admitting fault in your software nor fixing it

from lsp.

It's not only with the id of the response, it's also that a value of 1.0 for textDocumentSync.change is not recognized.

from lsp.

The LSP spec says https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocumentSyncKind

The LSP spec doesn't have fractional parts for textDocumentSyncKind

from lsp.

The LSP spec says nothing about fractional parts, the messaging is in JSON, and by the JSON spec, 1.0 is the same as 1.

Also, the LSP spec defines integers as JavaScript to be number

Do what you like though

from lsp.

The place you've linked defines integer, uinteger and decimal explicitly. All are mapped to number, I guess due to it being based on typescript typing system but that doesn't mean that decimal values are allowed in place of integer and uinteger. And for sure not in place of enum values which might technically be numbers under the hood in typescript case but spec doesn't specify that.

from lsp.

The LSP specification can impose additional restrictions on top of JSON specification and as far I understand this is what is happening here. You can ask at LSP specification repo if you think otherwise.

from lsp.