Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to drop deny_unknown_fields annotations #595

Open
jez opened this issue Oct 25, 2020 · 1 comment
Open

Option to drop deny_unknown_fields annotations #595

jez opened this issue Oct 25, 2020 · 1 comment

Comments

@jez
Copy link

jez commented Oct 25, 2020

This feature request is a follow up to this PR:

#448

Specifically, there was a comment:

I like strict more... jsonrpc provides a way to send arbitrary data in a params field, so I don't see a reason why someone would need to use other fields

While there is the params field for requests, for responses there is just result or error.

The use case that I have for extra top-level fields is that in some languages it's really annoying to have to deserialize untagged unions. The easy fix is to add an extra tag, that can then be ignored by tools that don't need to look for it. If I ever want to look at a JSON RPC response that I know my code serialized, I can look for that extra field, treat it as a tag, and then deserialize according to the value of that tag.

I would like to urge you all to add this back as an option. We would love to make use of it in LanguageClient-neovim. Language Server Protocol clients want to be as permissive as possible to accommodate as many language servers as possible (consider: we can't fix all the language servers, so we try to accomodate them).

A flag to optionally skip the deny_unknown_fields would be appreciated.

@tomusdrw
Copy link
Contributor

tomusdrw commented Nov 8, 2021

Related: #649

The non-strict mode could disregard members casing (but not method casing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants