I guess it's not needed. I know that the json unmarshaller requires a pointer to a struct... so for consistency, I was just stating it as a pointer. I had no idea that make(map) returns *hmap.
On Tuesday, January 30, 2018 at 9:13:28 AM UTC-6, matthe...@gmail.com wrote: > > Dave talks about map representation here: > https://dave.cheney.net/2017/04/30/if-a-map-isnt-a-reference-variable-what-is-it > > I don’t understand why you need a pointer to a map, can you provide a code > example? > > Matt > > On Tuesday, January 30, 2018 at 8:22:54 AM UTC-6, Trig wrote: >> >> Appreciate the response. I'm wanting to pass a *map[string]interface{} >> where the keys (strings) are already populated. I'm thinking of just >> creating a func which does this itself... checks to see if the keys exists >> and populate accordingly, and if not... return an error. Don't think this >> will be too difficult; however, would be a nice feature to discuss about >> being implemented into the json standard library. >> >> On Tuesday, January 30, 2018 at 5:31:01 AM UTC-6, Konstantin Khomoutov >> wrote: >>> >>> On Sun, Jan 28, 2018 at 10:59:58AM -0800, Trig wrote: >>> >>> > This works as intended when you pass it a pointer to a Struct; >>> however, it >>> > should also work (you would think, since the Unmarshaller can handle >>> both >>> > types) a pointer to a *map[string]interface{}; however, it does not. >>> Are >>> > there any future plans to implement this option on both types? >>> >>> You're talking about [1], are you? >>> >>> If yes, the commit [2] which closed it specifically talks about struct >>> types, so the function behaves as documented. >>> >>> On the other hand, I have two questions to narrow the scope of your >>> claim down. >>> >>> - To carry out its intended task, DisallowUnknownFields() has to >>> operate >>> on a value which it can use to figure out the set of known fields. >>> >>> In the case of a map this suggests that the map passed to that method >>> must be populated with the keys which would define the names of >>> the known fields (and the values assigned to those keys are expected >>> to be overwritten by the decoding process). Is this what you're >>> proposing? >>> >>> - Why a pointer to a map? >>> >>> In my eyes, this suggests that you may legitimately pass a pointer >>> to an unitialized map value and expect the decoder to create one for >>> you; is that correct? >>> >>> If "yes" is the answer to the both points, they cannot be satisfied >>> together: to fulfill the first requirement the map value must be >>> non-nil, >>> and you cannot expect the decoder to initialize it for you. >>> >>> All in all, I suggest you to create a proposal in the issue tracker. >>> Just be sure to be crystal clear, when laying it out -- to save the devs >>> from guessing what you really meant. >>> >>> 1. https://github.com/golang/go/issues/15314 >>> 2. >>> https://github.com/golang/go/commit/2596a0c075aeddec571cd658f748ac7a712a2b69 >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
