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

encoding/json: would like more tags #2514

Closed
gopherbot opened this issue Dec 1, 2011 · 7 comments

Comments

Projects
None yet
2 participants
@gopherbot
Copy link

commented Dec 1, 2011

by ultrotter@google.com:

The following tags would be useful in struct descriptions

`json:",required"`

fail parsing if this field is not present in the input json

`json:",ignore"`

don't marshal this field in the output json, and don't try to unmarshal it

moreover for slice fields a max/min length could be handy.
@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 1, 2011

Comment 1:

I am skeptical about required.  I don't want to turn this into
the mega-complexity that is protocol buffers.
Ignore is already there: use `json:"-"`.

Status changed to Thinking.

@gopherbot

This comment has been minimized.

Copy link
Author

commented Dec 1, 2011

Comment 2 by ultrotter@google.com:

Agreed about not having it super-complex.
But at the same time it's useful if I can just declare once what I expect and have it
parsed, rather than having to check later all the time that the required fields are
indeed present.
Thanks,
Guido
@gopherbot

This comment has been minimized.

Copy link
Author

commented Dec 1, 2011

Comment 3 by ultrotter@google.com:

q) would you consider some method that Unmarshal could call on an object if the object
supports it, and that would allow it to do more check/personalization in the parsing?
Thanks,
Guido
@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2011

Comment 4:

Labels changed: added priority-later.

@gopherbot

This comment has been minimized.

Copy link
Author

commented Sep 6, 2012

Comment 6 by jordanorelli:

I'd love to toss in a +1 for a `,permitnull` option.  The permitnull option would
substitute null for the zero value of a given type.  I.e., if you have a field declared
thusly:
    Url string `json:"url,permitnull"`
and you receive null in some json input, it is unmarshaled to an empty string.
https://dev.twitter.com/docs/api/1.1/get/users/lookup is a good example of what I'm
talking about: they have fields that should be string that return null instead of just
leaving the key off or returning the empty string.
of course, once you use ",permitnull", you'll be unmarshalling null into empty string,
and then marshaling it back to empty string instead of null, so it's a consistency
breaker.  Since it's opt-in, I find this to be an acceptable risk, but I could see why
it may be decided that this is not acceptable and prevents any such ",permitnull" option
from ever appearing.
there's also the "just use *string" argument, but I'm wary of having structs with a
large number of *string fields in an exported interface.
@gopherbot

This comment has been minimized.

Copy link
Author

commented Sep 7, 2012

Comment 7 by ultrotter@google.com:

Note that you could explicitly say whether you want a "zero" field to be encoded or left
out as well, to solve that problem.
Thanks,
Guido
@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 8:

Status changed to WontFix.

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.