I think it'll bite some people, but probably is the better default for JSON specifically. Most of the nil-maps-become-null thing is just an extension of Go defaulting to nil for empty arrays and maps, which is usually not what you expect when you're writing a JSON schema like
reply type ListUsersResponse struct {
Users []User `json:"users"`
}
userRows := db.Query(...)
var users []api.User
for _, user := range userRows {
users = append(users, api.User{...})
}
> Most of the nil-maps-become-null thing is just an extension of Go defaulting to nil for empty arrays and maps, which is usually not what you expect when you're writing a JSON schema
replyThis is definitely not what I expect in other language. I would argue this is a quick of Go though and not JSON's fault.
Can you explain why? This seems like the appropriate expectation to me, given how JSON is constructed and consumed.
replyNot the OP, but serializing both nil and empty arrays to the same json string means round tripping will not work for all objects.
replyThat seems like a bad default to me.
How is this a broken default? In Go, I almost always want a nil slice to be treated exactly as an empty slice, and JSONv1 was the ~only place this didn’t work as expected, leading to frequent bugs.
replyThe root cause is this idea of "zero values". Any de/serialization in go will always be crutchwork of guessing and incorrect validation.
replyJust look at the inane rules for map and slice access, what gets nil, what gets the zero value, which built-in mist be used. Even if that were consistent, then you'd still left to wonder if json.field was truly zero or not there.
[flagged]
reply