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.
