Enable read is easy. But by the current implementation, all the comments will be removed everytime the tool CRUD command is used
@livarcocc @nguerrera
The current API available is the lowest-level. Like the following. The higher level API like jsondocument and de/serializer will ignore or remove them when write.
I don't think I can easily re-write read and write using the lower-API in time. Do you think we should "unblock + document but will remove all comments if the user ever used CRUD command" or block writing comments for now? At the same time I will push for support of higher level API
```c#
string jsonString = "{"foo": 123, // some commentrn "bar": 456}";
var readerOptions = new JsonReaderOptions { CommentHandling = JsonCommentHandling.Allow };
var reader = new Utf8JsonReader(Encoding.UTF8.GetBytes(jsonString), readerOptions);
string comment = null;
while (reader.Read())
{
if (reader.TokenType == JsonTokenType.Comment)
{
comment = reader.GetComment();
}
}
```
I'm willing to wait and see past 3.0 RTM on this. Since we can always add comment support, but can't remove it, we can leave it out of the first version of local tools. We should monitor feedback and relay to corefx to give us a DOM like API that we can read/write and preserve comments as I can do with System.Xml.
I think our general principle should remain that we are permissive in files that users hand-edit, but it makes sense that we should equally design any CRUD over such a file to preserve comments, which is not really practical at this time with System.Text.Json. So we would be making a (temporary) exception to that principle based on that.
So it turns out that Json.NET makes this hard too. Without this capability available, I think JSON isn't well suited to documents maintained by a mix of humans and machines. Even without comments, reformatting everything will make noisy diffs. XML stack handles this all very well.
Anyway, enough venting on that, I don't think we need to be concerned about the push back. Waiting and seeing what feedback we get on this is still a viable approach. If we get enough we can return to that issue and point to it. If we don't get the feedback, then we can leave it without comment support.