BTW I have found an interesting usage for embedding type aliases. Assume a type A embeds another type B that has a member named B. That will cause a compilation error since A has two members named B. Now if a type alias be defined as type OrigB = B, then A can embed OrigB without any problems.
On Tuesday, January 23, 2018 at 9:59:10 PM UTC+3:30, Kaveh Shahbazian wrote: > > 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> 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 >> >> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe <rogp...@gmail.com> 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> >>> 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 >>> > >>> > 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.ko...@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...@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...@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.
