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://blog.merovius.de/2015/07/29/backwards-compatibility-in-go.html>. > 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 >> <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.
