Did not try that and changed that instance of this code. On Tuesday, January 23, 2018 at 9:04:36 PM UTC+3:30, rog wrote: > > Have you tried out the behaviour on Go tip (or the go 1.10 beta)? > > On 23 Jan 2018 14:31, "Josh Humphries" <j...@fullstory.com <javascript:>> > wrote: > > Roger, > I don't believe that patch will change behavior. See my last message: the > fields appear to be unexported according to reflection. > > That patch has the encoding/json package checking StructField.PkgPath, > which should be blank for exported fields. For these fields, it is > "go.builtin", which appears to be a pseudo-package name for builtins > (interestingly, it's not just "builtin" which is what Go doc would lead one > to expect). That means it will behave the same and skip the three fields in > question. > > This is non-intuitive based on the language spec, since the field names > are upper-cased. I think this is either a bug in reflect -- which should > set StructField.PkgPath to "" since the field name is exported -- OR a bug > in the compiler which should complain that there are three fields whose > resolved name appears to be the unexported identifier "int". > > > ---- > > Josh Humphries > > FullStory <https://www.fullstory.com/> | Atlanta, GA > > Software Engineer > > j...@fullstory.com <javascript:> > > On Tue, Jan 23, 2018 at 3:44 AM, roger peppe <rogp...@gmail.com > <javascript:>> wrote: > >> This is a bug that has been fixed on Go tip by >> https://go-review.googlesource.com/c/go/+/65550. >> >> >> On 23 January 2018 at 00:45, Josh Humphries <jh...@bluegosling.com >> <javascript:>> wrote: >> > I think have misspoken. Even though the field's name appears exported >> via >> > reflection (it has a name that starts with a capital letter), >> attempting to >> > use the reflect.Value's SetInt method panics, indicating that the field >> was >> > obtained using an unexported field. So the encoding/json package is thus >> > consistent with that in that it ignores unexported fields. >> > >> > It is still not obvious from the spec what should be happening. I would >> > expect it to be exported due to the resolved field name. But if it is >> > unexported because the compiler resolves the alias first, then I would >> > expect a compiler error because the four fields all resolve to the same >> > name. The spec states this is not allowed: >> > >> > The following declaration is illegal because field names must be unique >> in a >> > struct type: >> > >> > struct { >> > T // conflicts with embedded field *T and *P.T >> > *T // conflicts with embedded field T and *P.T >> > *P.T // conflicts with embedded field T and *T >> > } >> > >> > So it is possible that this is not a bug in the encoding/json package >> but in >> > the compiler. >> > >> > ---- >> > Josh Humphries >> > jh...@bluegosling.com <javascript:> >> > >> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries <jh...@bluegosling.com >> <javascript:>> >> > wrote: >> >> >> >> I think that is expected, and it is the JSON marshaling that is >> surprising >> >> (and erroneous). >> >> >> >> If it were expected that the embed field names resolved to the alias >> >> target type name, it would instead be a compiler error since the >> compiler >> >> does not allow embedded types that would result in name collisions. >> Using >> >> reflection, one can see the fields are named just as in your example, >> after >> >> the type aliases, not its underlying type name. The bug is that JSON >> >> marshaling is not looking at the field name and instead looking >> directly at >> >> the field type name (which, in this case, has been resolved to int). >> >> >> >> ---- >> >> Josh Humphries >> >> jh...@bluegosling.com <javascript:> >> >> >> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak >> >> <dan.ko...@adelaide.edu.au <javascript:>> wrote: >> >>> >> >>> This is sort of surprising though: >> https://play.golang.org/p/mjfkzIqAo_b >> >>> >> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote: >> >>> > From the Language Specification - >> >>> > >> >>> > A field declared with a type but no explicit field name is called an >> >>> > *embedded >> >>> > field*. An embedded field must be specified as a type name T or as a >> >>> > pointer to a non-interface type name *T, and T itself may not be a >> >>> > pointer >> >>> > type. The unqualified type name acts as the field name. >> >>> > >> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and >> >>> > *P.T4 >> >>> > struct { >> >>> > T1 // field name is T1 >> >>> > *T2 // field name is T2 >> >>> > P.T3 // field name is T3 >> >>> > *P.T4 // field name is T4 >> >>> > x, y int // field names are x and y >> >>> > } >> >>> > >> >>> > >> >>> > From the encoding/json#Marshal documentation - >> >>> > >> >>> > Struct values encode as JSON objects. Each exported struct field >> >>> > becomes a >> >>> > member of the object, using the field name as the object key, unless >> >>> > the >> >>> > field is omitted for one of the reasons given below. >> >>> > >> >>> >> >>> -- >> >>> 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...@googlegroups.com <javascript:>. >> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> > >> > -- >> > 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...@googlegroups.com <javascript:>. >> > For more options, visit https://groups.google.com/d/optout. >> > > >
-- 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.
