3 ms·
The main point of the article to me is "adding fields to Go structs is a breaking change" since your users could be using implicit struct initializer syntax, wh
by alpb 10y ago
The main point of the article to me is "adding fields to Go structs is a breaking change" since your users could be using implicit struct initializer syntax, which will cause a compilation error. They have listed other points too, but I think this one can be highlighted.
- twotwotwo 10y agoUsing the unkeyed initializer syntax is discouraged anyhow: https://golang.org/cmd/vet/#hdr-Unkeyed_composite_literals https://golang.org/cmd/vet/#hdr-Unkeyed_composite_literals Unkeyed syntax also doesn't work for a struct in another package with at least one private field. One common exception is a vector type that isn't expected to change--RGBA, XYZ, LatLon, etc.
- Merovius 10y agoThe issue is that even if you only consider keyed initializers, adding fields is a breaking change, strictly speaking. I tried making clear that I use the compatibility guarantee as a basis in the introduction and I mention this exception more thoroughly in the section about adding fields.