Thing is, since keyed fields are almost always better, why were unkeyed fields even allowed for struct literals? I see what you mean in your example, but I think it would be simpler to only have unkeyed fields.
Was it a mistake or is there a even better reason? > On Aug 12, 2016, at 10:12 PM, Nate Finch <nate.fi...@gmail.com> wrote: > > 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. -- 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.
