proposal: encoding/json: add "readonly" tag #28143
Previous discussion: #19423
Note: this proposal focuses on the encoding/json package, but the same could be
It is currently hard to marshal json while preventing those fields being set to
This is a common requirement in for example REST APIs:
When showing the data to the user (e.g.
As far as I can think of, right now it's hard to write a generic fully correct
The text was updated successfully, but these errors were encountered:
Quickly skimming this without reading into details, it's confusing if the
I don't really have very string opinions at any rate. At this point I think it's more important to discus the general concept and behaviour; the exact name can be changed easily.
Are there good use cases for that @deanveloper? I can't really think of any myself, but that could be a failure of my imagination.
I think it's important to identify practical real-world use cases that can't easily be implemented using exciting features, instead of just saying "hey, it might be nice to have ..."
For reasons of future-proofing and security it would be desirable to tag
I already explained my communication issue, remember that JSON is used in multiple areas, not just in data transmission but also in data storage and data display (which are both arguably "data transmission" but with the JSON ending up in a file/screen rather than a structure)
The communication issue in a "readonly" tag comes in when I see it outside the context of a data transmission. A simple example where "readonly" is confusing would be where JSON is used as a storage system, where "reading" is the Unmarshal step, you may think it's safe to read config values into "readonly" tags, especially if you have no intentions of changing your config during execution. This would result in no values being read, as what "readonly" really does is block the Unmarshal step.
Although you are correct that naming can be judged later.
This was more meant of a random thought and not really meant to add to our much to the conversation, although it may be useful for a similar case, but where the Unmarshal/Marshal mean Write/Read rather than vice versa.
I definitely agree here. If there's no use, then by all means we don't need a "no-marshal"
I hate pinging you, but is there any chance this can be reviewed @rsc? It's been quite a while and this was created before the current proposal review process. Could it be reviewed with it? I'm not entirely sure what the plans for the mentioned "JSON sweep" are?
I still run in to this; and AFAIK there isn't a clear solution, and this change (which should be fairly low-impact as far as I can tell) would be rather helpful