encoding/json: Add "nonil" struct tag for json encoding of nil slices/maps #27813

pjebs · 2018-09-22T09:26:38Z

add "nonil" struct tag for json marshaling slices/maps so that nil slices/maps get encoded as []/{} respectively.

googlebot · 2018-09-22T09:26:41Z

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

pjebs · 2018-09-22T09:35:36Z

I signed it!

googlebot · 2018-09-22T09:35:38Z

CLAs look good, thanks!

gopherbot · 2018-09-22T09:36:14Z

This PR (HEAD: 40e395c) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/136761 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2018-09-22T09:36:50Z

Message from Gerrit User 5976:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2018-09-22T09:59:41Z

Message from Gerrit User 12446:

Uploaded patch set 2: Commit message was updated.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2018-09-22T10:00:23Z

Message from Gerrit User 12446:

Uploaded patch set 3: Commit message was updated.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2018-09-22T16:24:01Z

Message from Gerrit User 9735:

Patch Set 3: Code-Review-2

Hi, thank you for your submission.

However, the proposal in #2278 would need to be accepted first because we start talking about concrete code changes.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2018-09-22T21:42:54Z

Message from Gerrit User 29344:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2018-09-22T21:44:45Z

Message from Gerrit User 9735:

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2018-09-22T22:55:37Z

Message from Gerrit User 29344:

Patch Set 3: Code-Review+1

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

#2278 seems to be about what the default behaviour should be. The issue is 7 years old so no-one will change the default behaviour anymore - not even for Go 2 - especially in light of Rob's comment.

My pull-request is not about default behaviour. It's about giving another option that does not conflict with current behaviour.

It's backwards-compatible.
It's minimally intrusive of the current API.
Any future changes in API that may interfere with this change can easily be accommodated for.
It brings Go inches closer to real-world usage rather than staying theoretical (eg. generics debate)

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2018-09-22T23:19:57Z

Message from Gerrit User 9735:

Patch Set 3:

Patch Set 3: Code-Review+1

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

#2278 seems to be about what the default behaviour should be. The issue is 7 years old so no-one will change the default behaviour anymore - not even for Go 2 - especially in light of Rob's comment.

My pull-request is not about default behaviour. It's about giving another option that does not conflict with current behaviour.

It's backwards-compatible.

It's minimally intrusive of the current API.

Any future changes in API that may interfere with this change can easily be accommodated for.

It brings Go inches closer to real-world usage rather than staying theoretical (eg. generics debate)

Specifying +1 on your own CL is unnecessary. The purpose of code review is for people other than yourself review the code and give their endorsement.

The acceptance criterion for adding new API is not simply whether it is backwards compatible. Every feature added should compose well with the set of features that came before it, otherwise we run into increasing number of edge cases where the behavior is obscure, surprising, and worse, leads to brittle and buggy code. This implies that each additional feature carries additional compound cost.

At the present there a number of encoding/json proposals and there needs to be a comprehensive review of all of them before adding new API ad-hoc. It may be that this feature actually does interact well with other proposed features, but that has yet to be determined.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2020-01-28T00:18:40Z

This PR (HEAD: ab41add) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/136761 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2021-11-08T12:02:07Z

Message from Gerrit User 9735:

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2021-11-08T12:02:08Z

Message from Gerrit User 29344:

Patch Set 3: Code-Review+1

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

#2278 seems to be about what the default behaviour should be. The issue is 7 years old so no-one will change the default behaviour anymore - not even for Go 2 - especially in light of Rob's comment.

My pull-request is not about default behaviour. It's about giving another option that does not conflict with current behaviour.

It's backwards-compatible.
It's minimally intrusive of the current API.
Any future changes in API that may interfere with this change can easily be accommodated for.
It brings Go inches closer to real-world usage rather than staying theoretical (eg. generics debate)

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2021-11-08T12:02:09Z

Message from Gerrit User 9735:

Patch Set 3:

Patch Set 3: Code-Review+1

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

#2278 seems to be about what the default behaviour should be. The issue is 7 years old so no-one will change the default behaviour anymore - not even for Go 2 - especially in light of Rob's comment.

My pull-request is not about default behaviour. It's about giving another option that does not conflict with current behaviour.

It's backwards-compatible.

It's minimally intrusive of the current API.

Any future changes in API that may interfere with this change can easily be accommodated for.

It brings Go inches closer to real-world usage rather than staying theoretical (eg. generics debate)

Specifying +1 on your own CL is unnecessary. The purpose of code review is for people other than yourself review the code and give their endorsement.

The acceptance criterion for adding new API is not simply whether it is backwards compatible. Every feature added should compose well with the set of features that came before it, otherwise we run into increasing number of edge cases where the behavior is obscure, surprising, and worse, leads to brittle and buggy code. This implies that each additional feature carries additional compound cost.

At the present there a number of encoding/json proposals and there needs to be a comprehensive review of all of them before adding new API ad-hoc. It may be that this feature actually does interact well with other proposed features, but that has yet to be determined.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

pjebs · 2021-12-15T19:39:30Z

Why was this closed?

heschi · 2021-12-15T19:43:22Z

I closed PRs older than a year to reduce load on the Gerrit importer. If you plan to continue work on it I'm happy to reopen, though I now realize that will create a new CL, sorry.

kris-watts-gravwell · 2023-04-21T18:42:48Z

Is there anything we can do to get this PR moving forward? Having to write custom MashalJSON methods on every single type that contains a slice introduces more code and API bloat than this tiny PR.

This PR is honestly very clean, concise, alters no default behavior and would allow many many projects that interface with external frameworks to rip out a bunch of nasty custom encoders.

Javascript really does not like to get a null when it expects an empty array, but that's what Go will send if your struct contains e.g. a []string and you don't explicitly initialize the slice. These custom marshallers make sure we send an empty array, making the frontend's life easier. Go desperately needs some way to tell the JSON encoder that we want this behavior, see: golang/go#37711 golang/go#27589 golang/go#27813

gopherbot · 2023-09-25T15:27:36Z

Message from Gerrit User 5976:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2023-09-25T15:27:37Z

Message from Gerrit User 9735:

Patch Set 3: Code-Review-2

Hi, thank you for your submission.

However, the proposal in #2278 would need to be accepted first because we start talking about concrete code changes.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2023-09-25T15:27:38Z

Message from Gerrit User 29344:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2023-09-25T15:27:38Z

Message from Gerrit User 9735:

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2023-09-25T15:27:39Z

Message from Gerrit User 29344:

Patch Set 3: Code-Review+1

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

#2278 seems to be about what the default behaviour should be. The issue is 7 years old so no-one will change the default behaviour anymore - not even for Go 2 - especially in light of Rob's comment.

My pull-request is not about default behaviour. It's about giving another option that does not conflict with current behaviour.

It's backwards-compatible.
It's minimally intrusive of the current API.
Any future changes in API that may interfere with this change can easily be accommodated for.
It brings Go inches closer to real-world usage rather than staying theoretical (eg. generics debate)

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2023-09-25T15:27:40Z

Message from Gerrit User 9735:

Patch Set 3:

Patch Set 3: Code-Review+1

Patch Set 3:

Patch Set 3:

It seems to me like this can still get merged whilst thinking about the prior proposal.

This CL adds new API that the prior proposal is trying to decide whether to add or not. I'm not sure I follow the rationale in accepting the outcome before the decision.

#2278 seems to be about what the default behaviour should be. The issue is 7 years old so no-one will change the default behaviour anymore - not even for Go 2 - especially in light of Rob's comment.

My pull-request is not about default behaviour. It's about giving another option that does not conflict with current behaviour.

It's backwards-compatible.

It's minimally intrusive of the current API.

Any future changes in API that may interfere with this change can easily be accommodated for.

It brings Go inches closer to real-world usage rather than staying theoretical (eg. generics debate)

Specifying +1 on your own CL is unnecessary. The purpose of code review is for people other than yourself review the code and give their endorsement.

The acceptance criterion for adding new API is not simply whether it is backwards compatible. Every feature added should compose well with the set of features that came before it, otherwise we run into increasing number of edge cases where the behavior is obscure, surprising, and worse, leads to brittle and buggy code. This implies that each additional feature carries additional compound cost.

At the present there a number of encoding/json proposals and there needs to be a comprehensive review of all of them before adding new API ad-hoc. It may be that this feature actually does interact well with other proposed features, but that has yet to be determined.

Please don’t reply on this GitHub thread. Visit golang.org/cl/136761.
After addressing review feedback, remember to publish your drafts!

added heednull option for json encoding

40e395c

googlebot added the cla: no Used by googlebot to label PRs as having an invalid CLA. The text of this label should not change. label Sep 22, 2018

googlebot added cla: yes Used by googlebot to label PRs as having a valid CLA. The text of this label should not change. and removed cla: no Used by googlebot to label PRs as having an invalid CLA. The text of this label should not change. labels Sep 22, 2018

pjebs mentioned this pull request Sep 22, 2018

proposal: encoding/json: "nonil" struct tag to marshal nil slices and maps as non-null #27589

Open

bradfitz force-pushed the master branch from c9b4dca to 8c5c2b7 Compare November 21, 2018 19:24

gopherbot force-pushed the master branch 3 times, most recently from 53bd915 to 6139019 Compare October 3, 2019 21:09

gopherbot force-pushed the master branch 7 times, most recently from 4a7ed1f to 0f992b9 Compare November 5, 2019 02:57

- change from "heednull" to "nonil"

ab41add

pjebs changed the title ~~encoding/json: added heednull option for json encoding~~ encoding/json: added nonil option for json encoding Jan 28, 2020

pjebs changed the title ~~encoding/json: added nonil option for json encoding~~ encoding/json: added nonil option for json encoding (slice/maps) Jan 28, 2020

pjebs changed the title ~~encoding/json: added nonil option for json encoding (slice/maps)~~ encoding/json: added "nonil" option for json encoding (slice/maps) Jan 30, 2020

lukebarton mentioned this pull request Mar 6, 2020

proposal: encoding/json: nilasempty to encode nil-slices as [] #37711

Open

kingreatwill mentioned this pull request Apr 29, 2020

added "nonil" option for json encoding slice json-iterator/go#456

Open

pjebs changed the title ~~encoding/json: added "nonil" option for json encoding (slice/maps)~~ encoding/json: Add "nonil" struct tag for json encoding of nil slices/maps May 8, 2020

gopherbot force-pushed the master branch from a408139 to 5764653 Compare September 14, 2020 21:26

This was referenced Oct 1, 2020

Policies and roles list should return empty array if list is empty ory/keto#217

Closed

fix: Use make() to initialise array of Policy and Role instead of leaving it uninitalised ory/keto#250

Merged

heschi closed this Dec 15, 2021

heschi reopened this Dec 15, 2021

john-floren-gravwell mentioned this pull request Apr 21, 2023

Add custom marshallers for some ABAC types. gravwell/gravwell#692

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

encoding/json: Add "nonil" struct tag for json encoding of nil slices/maps #27813

encoding/json: Add "nonil" struct tag for json encoding of nil slices/maps #27813

pjebs commented Sep 22, 2018 •

edited

Loading

googlebot commented Sep 22, 2018

pjebs commented Sep 22, 2018

googlebot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Jan 28, 2020

gopherbot commented Nov 8, 2021

gopherbot commented Nov 8, 2021

gopherbot commented Nov 8, 2021

pjebs commented Dec 15, 2021

heschi commented Dec 15, 2021

kris-watts-gravwell commented Apr 21, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

encoding/json: Add "nonil" struct tag for json encoding of nil slices/maps #27813

Are you sure you want to change the base?

encoding/json: Add "nonil" struct tag for json encoding of nil slices/maps #27813

Conversation

pjebs commented Sep 22, 2018 • edited Loading

googlebot commented Sep 22, 2018

What to do if you already signed the CLA

Individual signers

Corporate signers

pjebs commented Sep 22, 2018

googlebot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Sep 22, 2018

gopherbot commented Jan 28, 2020

gopherbot commented Nov 8, 2021

gopherbot commented Nov 8, 2021

gopherbot commented Nov 8, 2021

pjebs commented Dec 15, 2021

heschi commented Dec 15, 2021

kris-watts-gravwell commented Apr 21, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

gopherbot commented Sep 25, 2023

pjebs commented Sep 22, 2018 •

edited

Loading