Unkeyed can be good to remind future you that you've changed the signature of a struct and are now not populating all the fields. That cuts both ways, since it means you *have* to go to every place you've created a value of that struct and update it with a new value... but it also means that if you don't have a good default for that new field, that you won't miss places it's used.
However, there's a negative here, too. If you change the *order* of fields in a struct, all your code using unkeyed fields is now (probably) wrong. In my experience, it's almost always better to use keyed fields. On Friday, August 12, 2016 at 9:16:50 PM UTC-4, Jesse McNelis wrote: > > On Sat, Aug 13, 2016 at 7:29 AM, Anmol Sethi <an...@aubble.com > <javascript:>> wrote: > > Keyed fields seem to be always better than unkeyed fields in a composite > literal. > > Under what circumstances would I want to use unkeyed fields? > > Keyed fields are better than unkeyed fields since keyed fields are > covered by the Go1 compatibility promise. > Use unkeyed fields when you're feeling lazy. > -- 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. For more options, visit https://groups.google.com/d/optout.
