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 <https://golang.org/ref/spec#Struct_types> 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 On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries <jh...@bluegosling.com> 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 > > On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak < > dan.kortsc...@adelaide.edu.au> 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+unsubscr...@googlegroups.com. >> 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.
