CC @bcmills

I don't see how we would implement UnmarshalJSON: sync.Map stores its values as type interface{}, so in general the Unmarshal method has no way to know what type of values to put into the map.

That would mean that UnmarshalJSON and MarshalJSON are not inverses: marshaling and then unmarshaling a map would potentially result in different key and value types from the original, even though the underlying map has the same concrete type.

I guess that MarshalJSON on its own would be ok, but it seems awkward to have one without the other.

I don't see how we would implement UnmarshalJSON: sync.Map stores its values as type interface{}, so in general the Unmarshal method has no way to know what type of values to put into the map.

The same way json.Unmarshal handles interface values. Unmarshaling into sync.Map would in that case be identical to unmarshaling into map[interface{}]interface{}.

That would mean that UnmarshalJSON and MarshalJSON are not inverses: marshaling and then unmarshaling a map would potentially result in different key and value types from the original, even though the underlying map has the same concrete type.

That is already the case for map[interface{}]interface{}.

The key difference vs. map[interface{}]interface{} is that it is very easy to choose some other (more-specific) built-in map type instead. In contrast, there is no typed alternative to sync.Map.

Note that if you want a marshal'able sync.Map you can always write your own type that embeds a sync.Map and adds whatever specific serialized format you need. Adding that specifically to package sync is a bit of a layer inversion. Sync is about synchronizing the map, not serialization formats.