Hacker News new | past | comments | ask | show | jobs | submit
SkiFire13 | on: A new Go API for JSON
> nil slices and maps are marshaled as an empty JSON array or object by default

I feel that is the kind of broken default that will come back and bite a bunch of people, and will eventually need to be fixed in a v3.

travisd | parent | next
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

    type ListUsersResponse struct {
        Users []User `json:"users"`
    }
in Go. It's pretty common have code like

    userRows := db.Query(...)
    var users []api.User
    for _, user := range userRows {
        users = append(users, api.User{...})
    }
where you don't _really_ intend for the default nil-ness to leak out. (Apologies for any broken syntax, I'm realizing in real time that it's been a while since I've written Go)
SkiFire13 | root | parent
> 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

This is definitely not what I expect in other language. I would argue this is a quick of Go though and not JSON's fault.

devmor | parent | next
Can you explain why? This seems like the appropriate expectation to me, given how JSON is constructed and consumed.
Someone | root | parent
Not the OP, but serializing both nil and empty arrays to the same json string means round tripping will not work for all objects.

That seems like a bad default to me.

throwaway894345 | parent | next
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.
the_gipsy | parent | next
The root cause is this idea of "zero values". Any de/serialization in go will always be crutchwork of guessing and incorrect validation.

Just 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.