My apologies this is already called out in apidiff's desiderata section under the Using an Identical Type Externally heading. https://pkg.go.dev/golang.org/x/exp/apidiff
This means that it is already apocrypha. Is there still discussion to be had about struct tags and marshaling, or should I open an issue for a vet lint? On Fri, 12 Mar 2021, 09:16 Brian Candler, <b.cand...@pobox.com> wrote: > On Friday, 12 March 2021 at 06:56:46 UTC axel.wa...@googlemail.com wrote: > >> On Fri, Mar 12, 2021 at 3:26 AM Robert Engels <ren...@ix.netcom.com> >> wrote: >> >>> I must be dense on this. I have no idea why there is any use of struct >>> tags or JSON marshaling in the sample code. >>> >> >> To demonstrate why converting between different struct types is useful. >> >> If you want take an struct existing type (defined in a different package) >> and change how it is marshalled (say, omit or rename a certain field) you'd >> have to create a new struct type with different tags and copy over the >> fields. This was deemed inconvenient >> <https://github.com/golang/go/issues/6858>, so it was changed to the >> current semantics in go 1.8 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__golang.org_doc_go1.8-23language&d=DwMFaQ&c=ncDTmphkJTvjIDPh0hpF_w&r=OaiRsMTFeJ0tMmMJQ5CwMuxNMvWoKXAJr-ebE3c5HU8&m=HSSqyMaV9WZcYwYjgGeTQVnh1Zbp5buKWiP4DsUUwjI&s=8d8XouA8CfqUNMl1ZngzPNzWf1t9HCXCJeTirvO1gRo&e=>. >> OP is pointing out that the change means adding a field to a struct is now >> a backwards incompatible change, as someone might to this conversion. >> > > I think I am also being dense. I can see two separate things under > discussion - compatibility of struct types for conversion, and > backwards-compatibility of serialization [JSON? Protobuf?] - but I can't > see what's being proposed to change. > > I don't follow the argument that "adding a field to a struct is *now* a > backwards incompatible change". Surely this was always the case, > regardless of tags? That is, if you have > > type T1 struct { > Foo string > } > > type T2 struct { > Foo string > Bar string > } > > then what would you expect to happen for: > > v1 := T1{} > v2 := T2(v1) ?? > ... > v2 := T2{} > v1 := T1(v2) ?? > > These two structures have different shapes. In the first case, I suppose > it could copy the matching members and create zero values for the new > ones. In the second case, I suppose it could copy the matching members and > silently(!) discard the missing ones. But either way, that just means the > compiler magically writing code which copies member-by-member. I'd rather > do this by hand. > > Even with magic conversions, trying to use a *t1 as a *t2 or vice versa > would definitely not work, as they have differing layout in memory. Indeed, > even the ordering of fields in memory must be the same for two structs to > be compatible: > https://play.golang.org/p/BTUc6mNJQKS > > However, if two structures have the same members in the same order, and > differ only by tags, then they have the same shape. Then it seems > reasonable to me to treat a T1 as compatible with T2; copying can be done > as a blob of bytes. The change in 1.8 to omit comparing tags has made > types more compatible, not less. > > Separately from that, there's the issue of serialization and > forwards/backwards compatibility. I don't see any problem here. For > example, if you serialize a type T1 to JSON, and then deserialize to T2 > (which may have more or fewer fields), that all works fine. > > https://play.golang.org/p/aJwObgyRhan > > If you want to reject unexpected fields when deserializing, there are > options for doing that. But by default, they are compatible in both > directions. You can also re-order the fields in the struct, since the JSON > deserialization is assigning elements individually. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/oAjxpH-Qq2Y/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/36e1a048-2505-4841-8882-a9b16a33fd57n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/36e1a048-2505-4841-8882-a9b16a33fd57n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CADJfOyUZgzh67Qo9D_Y2Wj6jPRi2wWtXVDCFzh-tA9QYDc5n2w%40mail.gmail.com.
