Joe Tsai

I'm remembering now that https://github.com/protocolbuffers/protobuf-go/blob/master/internal/encoding/json is currently implemented only in terms of `[]byte`. Switching it to a `io.Reader` and `io.Writer` isn't trivial. Option 1: Buffer entirely * For writing, buffer...

BTW, a formal proposal for "encoding/json/v2" along with "encoding/json/jsontext" has be filed at golang/go#71497.

Hi, thanks for reporting the issue, but this is almost certainly a upstream issue.

I support a strong deprecation message. Would that message endorse the Gorilla implementation? If we implement golang/lint#238, I think that will help people avoid wasting time developing with deprecated packages...

[RFC 8259, section 2](https://datatracker.ietf.org/doc/html/rfc8259#section-2) uses the terms `begin-array`, `begin-object`, `end-array`, and `end-object` as the formal grammatical names for these constructs. We aim to use proper JSON terminology if relevant. As...

> ...although if we do that, I think the values should be integers (iota+1, etc.) rather than characters. We tried that in the past, and renumbering the constants was also...

We discussed this in the json/v2 proposal meeting and plan on adding named constants for the kinds: ```diff const ( + KindInvalid Kind = 0 + KindNull Kind = 'n'...

We discussed this in the json/v2 proposal meeting. Switching the default to reject missing fields is pretty-much a non-starter as @majewsky noted. As far as I can tell, the most...

Moving this to the "Post-Proposal" state as we definitely can't change the default behavior regarding required fields. Future API to somehow safely add this functionality could be added after the...

We discussed this in the json/v2 proposal meeting and we're leaning towards: 1. Adding a `KindInvalid` constant (see #71756 ). 2. Making sure the API actually returns `KindInvalid` for invalid...