Can you elaborate/link to example code? Because it seems to work just fine <https://play.golang.org/p/P0gUjbf6qRD>.
On Wed, Feb 28, 2018 at 6:58 PM Kaveh Shahbazian <kaveh.shahbaz...@gmail.com> wrote: > 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. > -- 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.
