>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.
On Monday, January 22, 2018 at 9:40:41 AM UTC-7, Axel Wagner wrote:
>
> You are right, I am wrong. I wasn't aware that the struct field would be
> named after the alias, I assumed it would be named after the type itself. I
> agree that this looks like a bug in the json-package and that it should
> look at the field name itself.
>
> On Mon, Jan 22, 2018 at 4:47 PM, Josh Humphries <jh...@bluegosling.com
> <javascript:>> wrote:
>
>> 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 <javascript:>
>>
>> On Mon, Jan 22, 2018 at 3:12 AM, 'Axel Wagner' via golang-nuts <
>> golan...@googlegroups.com <javascript:>> wrote:
>>
>>> On Mon, Jan 22, 2018 at 8:50 AM, dc0d <kaveh.sh...@gmail.com
>>> <javascript:>> 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...@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.
