In go, the Marshall and unmarshal functions take `any` for the source or destination. If you use a value of a type that doesn't support marshaling or unmarshalling (say because it contains an unserializable type like a channel, function pointer, etc) then you get a runtime error. Whereas in rust, Haskell, scala, etc. you can get a compile time error if you try to use a type that doesn't support serialization.
You don’t get runtime errors for marshalling pointers to JSON. I actually do this all the time. What you get is the address of the pointer marshalled.
I think the same is true for channels too but I’m not near a computer to check.
> You don’t get runtime errors for marshalling pointers to JSON
https://pkg.go.dev/encoding/json/v2#Marshal says otherwise:
> The Go map key must encode as a JSON string, otherwise this results in a SemanticError
> All other Go types (e.g., complex numbers, channels, and functions) have no default representation and result in a SemanticError.
v1 has the same constraints.
> A Go pointer is encoded as a JSON null if nil, otherwise it is the recursively JSON-encoded representation of the underlying value.
The doc you linked to literally proves me right.
That just shows there are pointer values that can be marshaled, not that all such values won't error. If you have a non-nil pointer that points to an object that transitively contains one of the unsupported types, you will get an error.
I read that differently. If you have a non-nil pointer then you get the address of the pointer irrespective of what that pointer points too.
I'm not sure how you are getting that from "otherwise it is the recursively JSON-encoded representation of the underlying value", but here is a playground example, where using a non-nil pointer to a channel produces an error:
https://go.dev/play/p/JXYuGUQ0TLQ
Compile time cannot check for runtime values (not even in Rust) - is your position that fields can only be populated at compile time?