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. 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. 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. >>>> But when the original struct has a field added, this breaks: >>>> https://play.golang.org/p/VHmV9r2MxNt. 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. >>> >>> -- >>> 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. > > -- > 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. -- 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/8DAFB3BC-D2F6-485C-9963-7A90DC82A623%40ix.netcom.com.
