Sweet, I will open up the proposal, unless there is mass descent to this idea.
I will call out that this WILL make implementing marshaling logic harder, but it seems orthogonal to the desire for a vet check to prevent random code breakage. On Mon, 15 Mar 2021, 23:31 Ian Lance Taylor, <i...@golang.org> wrote: > 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://urldefense.proofpoint.com/v2/url?u=https-3A__golang.org_doc_go1compat&d=DwIBaQ&c=ncDTmphkJTvjIDPh0hpF_w&r=OaiRsMTFeJ0tMmMJQ5CwMuxNMvWoKXAJr-ebE3c5HU8&m=BwDgsUE5_LEEW5RxBIHVgubBBU6sjTmHByGINoQdumY&s=eo85CA9Hql7PSY99KGPgRBnHzFithGMWr8rpoxoSLeY&e= > : > > 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/oAjxpH-Qq2Y/unsubscribe. > To unsubscribe from this group and all its topics, 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 > . > -- 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/CADJfOyXCBew7_W7pkzvmst4GWraXh_i6FRYQsQLivTRmw%2BPS2g%40mail.gmail.com.
