proposal: Struct field tags for directional Marshal/Unmarshal

[casimcdaniels]

The current package provides the following json tag capabilities as specified in the docs:

// Field is ignored by this package.
Field int `json:"-"`

// Field appears in JSON as key "myName".
Field int `json:"myName"`

// Field appears in JSON as key "myName" and
// the field is omitted from the object if its value is empty,
// as defined above.
Field int `json:"myName,omitempty"`

// Field appears in JSON as key "Field" (the default), but
// the field is skipped if empty.
// Note the leading comma.
Field int `json:",omitempty"`

A feature I propose is an additional set of tag parameters that allow for definition of the directional conditions to marshal/unmarshal.

// Field appears in JSON as key "myName" and
// the field is omitted from the object when unmarshalled

Field int `json:"myName,marshalonly"`


// Field appears in JSON as key "myName" and
// the field is omitted from the object when marshalled

Field int `json:"myName,unmarshalonly"`

[minux]

Why?

[casimcdaniels]

@minux There have been several occasions where I have had to implement marshaller methods to filter out fields depending on where the data is going. For example, in my models in an MVC application I sometimes like certain attributes to not be Marshalled, say a foreign key for an embedded type, back to the client and only allow it to be Unmarshalled from a request to set and perform business logic on.

As I said, I do this already with the MarshalJSON/UnmarshalJSON, though it seems redundant when there already exists a similar functionality for omitempty.

[minux]

In such applications, it's probably better to create separate structs that don't have unneeded fields.

[bradfitz]

Yeah, as @minux suggested, it's probably better to just use two structs. As of Go 1.8 this is now easier. See https://beta.golang.org/doc/go1.8#language

I'm going to decline this proposal, because the json package is pretty locked down at this point and it seems like there's already a solution. Even if the solution might not be ideal for you, it's probably better than complicating the json package for everybody else.

[casimcdaniels]

@bradfitz What's the reasoning behind the omit ´json:"-"´option as that seems essentially the same. I could just create a struct that doesn't contain that field, but its cleaner and less copying to add the tag.