It may be worth noting that we already have a vet check for composite
literals that verifies that if a composite literal is used with a
struct defined in a different package, then the fields are explicitly
named. This check means that adding fields to a struct will never
break composite literals in other packages. This corresponds to this
comment in https://golang.org/doc/go1compat:
Struct literals. For the addition of features in later point
releases, it may be necessary to add fields to exported structs in the
API. Code that uses unkeyed struct literals (such as pkg.T{3, "x"}) to
create values of these types would fail to compile after such a
change. However, code that uses keyed literals (pkg.T{A: 3, B: "x"})
will continue to compile after such a change. We will update such data
structures in a way that allows keyed struct literals to remain
compatible, although unkeyed literals may fail to compile. (There are
also more intricate cases involving nested data structures or
interfaces, but they have the same resolution.) We therefore recommend
that composite literals whose type is defined in a separate package
should use the keyed notation.
I think it would be consistent with that to add a vet check that would
warn about attempts to convert a struct defined in a different package
to a locally defined struct.
Ian
--
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/CAOyqgcXejyPtRM-sUN_JkcsP24Y2dqfPeqdensbOzmpbKF9r5Q%40mail.gmail.com.
