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.
