Nobody seems in favour of making this a "technically" breaking change, like changing the value of a string constant, though I think there is an argument. Does it seem reasonable to add a vet lint for this type of struct type conversion? Or is more discussion warranted?
I am looking to eventually drive to a proposal for some doc, convention change to attempt to prevent such breakage in the future. On Fri, 12 Mar 2021, 06:56 Axel Wagner, <axel.wagner...@googlemail.com> wrote: > On Fri, Mar 12, 2021 at 3:26 AM Robert Engels <reng...@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=NFZSarD8QtZBLmJpKB49KMwdSOYZ4dSY_b2L9uR_c6w&s=EEex7dZCE7_Hv_rS6qkY5C10Hta4F4lmxIPtOAVOdR8&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. > Though to be clear, it would've been before the change as well, as someone > can define a new struct type with the same tags and do the conversion and > run into the same problem. It's just that the change made converting > between different struct types a lot more common. > > There are still cases where converting between different struct types is > useful - e.g. in the case of the person who filed the original issue, they > control the different instances of that struct, so they don't suffer from > breakages if they change it. But in general, these kinds of conversions > seem inadvisable, if you don't control both instances of the struct. > > >> It will fail without any of that. >> >> On Mar 11, 2021, at 5:28 PM, Axel Wagner <axel.wagner...@googlemail.com> >> wrote: >> >> >> That seems unrelated to this thread. If you add a field to a >> proto-message and try to do the same struct-conversion Colin mentions, you >> will run into exactly the same problem. We are talking about language >> facilities here, not third party code generators. >> >> On Thu, Mar 11, 2021 at 11:48 PM Robert Engels <reng...@ix.netcom.com> >> wrote: >> >>> If you use protobufs and the current guidelines you can always add new >>> fields. >>> >>> On Mar 11, 2021, at 12:43 PM, 'Axel Wagner' via golang-nuts < >>> golang-nuts@googlegroups.com> wrote: >>> >>> >>> Hi, >>> >>> in some sense, every change to an exported symbol is a breaking change >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.merovius.de_2015_07_29_backwards-2Dcompatibility-2Din-2Dgo.html&d=DwMFaQ&c=ncDTmphkJTvjIDPh0hpF_w&r=OaiRsMTFeJ0tMmMJQ5CwMuxNMvWoKXAJr-ebE3c5HU8&m=NFZSarD8QtZBLmJpKB49KMwdSOYZ4dSY_b2L9uR_c6w&s=S0ssSMrsv4QQZv3S9gaG5tDfO-qUpPxQ2Pdfdjsk3h4&e=>. >>> So a straight-forward "does this change have the potential to break a >>> reverse dependency" is simply not the best way to look at compatibility. We >>> need more nuance. >>> >>> In general, I believe it would be fair to tell the consumer of a struct >>> that if they want to be guarded against this kind of breakage, they can't >>> use the conversion-ignoring-struct-tags utility, but have to copy the >>> fields one by one. That is similar to how we already tell the consumers of >>> a struct that they need to use struct-literals with field-names. >>> >>> To the producer I would say that they should consider how a struct is >>> used, to decide if something is a breaking change or not. For example, I >>> believe it would be fair to assume that an http.Server is not something >>> that would be serialized so there would likely be little need to consider >>> adding a struct field a breaking change. But something like a jwt token, or >>> other plain-old-data struct types should probably be aware of this and >>> might have to consider adding a field a breaking change. >>> >>> In either case, I think you bring up an interesting case that I haven't >>> thought about, before. Personally, I feel that at its core, the approach of >>> controlling encoding behavior via struct tags just isn't friendly towards >>> other packages re-using the same type, but changing encoding aspects. >>> Allowing conversions to ignore struct tags was a way to remedy that, but as >>> you demonstrate, that's still far from ideal. >>> >>> So perhaps what we should do is discourage new encoding packages from >>> coupling options to the type itself and instead encourage pass them to the >>> encoder directly - or at least providing the option to do so. At the end of >>> the day, Go gives authority over a type to the package defining it, both in >>> terms of what the language allows and in terms of domains of breaking >>> changes. So if we want to enable people to re-use a type with different >>> encodings, we should have a way to customize the encoding behavior of types >>> without having to touch them directly. >>> >>> On Thu, Mar 11, 2021 at 6:15 PM 'Colin Arnott' via golang-nuts < >>> golang-nuts@googlegroups.com> wrote: >>> >>>> When working with wire formats, serialisation, and external types, it >>>> is useful to change the struct tags: >>>> https://play.golang.org/p/h6b6FmeDuaR >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__play.golang.org_p_h6b6FmeDuaR&d=DwMFaQ&c=ncDTmphkJTvjIDPh0hpF_w&r=OaiRsMTFeJ0tMmMJQ5CwMuxNMvWoKXAJr-ebE3c5HU8&m=NFZSarD8QtZBLmJpKB49KMwdSOYZ4dSY_b2L9uR_c6w&s=NH0k5XqnStfTYG3Qh2e6J7w5tX_ARKqe0enHdrZ44TQ&e=>. >>>> But when the original struct has a field added, this breaks: >>>> https://play.golang.org/p/VHmV9r2MxNt >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__play.golang.org_p_VHmV9r2MxNt&d=DwMFaQ&c=ncDTmphkJTvjIDPh0hpF_w&r=OaiRsMTFeJ0tMmMJQ5CwMuxNMvWoKXAJr-ebE3c5HU8&m=NFZSarD8QtZBLmJpKB49KMwdSOYZ4dSY_b2L9uR_c6w&s=27fKcSYd8W4tj4OHKCCrXjDDtun1lqMeo6byaqBj5Q8&e=>. >>>> It seems like a foregone conclusion that we suggest against adding a struct >>>> field because it is a breaking change. That said, we probably do not want >>>> to restrict the ability to convert structs as it is really helpful. Is this >>>> a known issue or previously discussed topic? If not what if anything should >>>> be done to clarify best practices? >>>> >>>> -- >>>> 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/dcdcbd6a-838e-47c1-8b3d-935d485d96b5n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/golang-nuts/dcdcbd6a-838e-47c1-8b3d-935d485d96b5n%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/CAEkBMfGp%2B%2B90tK1A-Sti1wjap%3DXxBU-QfrE1ReUSCYDt75tmHQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGp%2B%2B90tK1A-Sti1wjap%3DXxBU-QfrE1ReUSCYDt75tmHQ%40mail.gmail.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/CAEkBMfHQciGzQoVPnch%2BuyUCjR6gnGzfk%3DBZvnc6ncMF-KYS%3Dw%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHQciGzQoVPnch%2BuyUCjR6gnGzfk%3DBZvnc6ncMF-KYS%3Dw%40mail.gmail.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/CADJfOyW-MgnBVtAoGe_HkfTbk1k1qsQz5WcNEqv0BHTHGFXtaw%40mail.gmail.com.
