Exactly. That's why I asked before why we are allowed to embed type aliases. It should be either not possible, or be properly handled by the type system (and tools).
On Tuesday, January 23, 2018 at 6:02:54 PM UTC+3:30, Josh Humphries 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.
