I'm not trying to suggest that the example code makes sense or is something that one *should* do.
But it is surprising behavior that is not expected, even after reading relevant parts of the language spec and the reflect and json package docs. It looks like this is a bug in the json package. When it encounters an anonymous field, it looks directly at the name of the field's type, instead of the name of the field itself, to decide whether the field is exported or not: https://golang.org/src/encoding/json/encode.go?s=6456:6499#L1097 In this case, the StructField's indicate exported names (based on the type alias names), but the field's type is simply int (which is not exported due to starting with lower-case letter). ---- *Josh Humphries* jh...@bluegosling.com On Mon, Jan 22, 2018 at 3:12 AM, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Mon, Jan 22, 2018 at 8:50 AM, dc0d <kaveh.shahbaz...@gmail.com> wrote: > >> Then the main question would be why is it possible to embed type aliases? >> > > Because it is possible to embed types and an alias is simply another name > for a type. > > For example, embedding an x/image/draw.Image > <https://godoc.org/golang.org/x/image/draw#Image> makes 100% complete > sense: It allows your type to be used as an Image itself, while adding or > overwriting some methods. And the alias makes x/image/draw a drop-in > replacement for image/draw, so you can use your embedding type also in > functions that expect an image/draw. Also note, that even with unexported > embedded types, you are *still* promoting fields and methods > <https://play.golang.org/p/k-223vmcfNJ>. > > In the end, the issue here boils down to: Aliases are a purely > compile-time feature. type Foo = Bar will *by definition* not introduce a > new actual type, but just an identifier to refer to the same type - that's > the point. Given that encoding/json works with reflection, so uses runtime > type information, it can't possibly know about your alias and will have to > assume you are embedding an int instead. And note, that embedding an int was > always possible <https://play.golang.org/p/70jzEBzq5Ov> - but always > sorta pointless. But why explicitly disallow it? If it ain't broke don't > fix it. > > Why are you even using aliases in your example? It would seem that those > things either shouldn't have a name at all (and instead be field names) or > they should be actual types. Probably the former. > > >> >> >> On Sunday, January 21, 2018 at 10:42:28 PM UTC+3:30, Kevin Malachowski >> wrote: >>> >>> Given the last playground post, I'd guess that the aliased type (i.e. >>> 'int' here) is being used for visibility rather than the alias's new name. >>> >>> It's also a little weird to use embedded types that dont need to be >>> (there's no method promotion here because 'int' has no methods), or seeing >>> aliases to primitive types. Do you need to do both of those things? >>> >> -- >> 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. > -- 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.
