I'm using unkeyed fields for the opposite reason: I don't want code to compile when I add new fields to the struct, unless this is reflected at the other end. For example, I found it very useful sometimes, to pass a long list of arguments to the function through a struct. The same would happen if I pass arguments directly and change signature of the function by adding arguments, so the code won't compile if this function is still being called with lesser number of arguments. But it could compile incorrectly, if I just change the order of the arguments of the same type.
On Thursday, January 7, 2016 at 6:33:20 PM UTC+3, Rob 'Commander' Pike wrote: > > The argument for the complaint is that keyed composite literals are more > future-proof. If you later change the layout of s, the code will fail to > compile if the keys no longer work, but an unkeyed literal may compile > incorrectly. In your example, if you swapped a and b in s, the first > assignment of z would set 1 to b and 2 to a. > > It also affects guarantees of compatibility. See > https://golang.org/doc/go1compat. > > -rob > > > On Thu, Jan 7, 2016 at 2:21 AM, Tamás Gulácsi <tgula...@gmail.com > <javascript:>> wrote: > >> Add keys - for >> type s struct{a,b int} >> Instead of z :=s{1,2} >> Use z :=s{a:1,b:2} >> >> -- >> 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 golan...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/0cb8f3c8-9551-4965-b427-f3a74f088ac2o%40googlegroups.com.
