On Sat, Aug 13, 2016 at 12:06 AM, Anmol Sethi <an...@aubble.com> wrote: > 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?
I think this is a case where consistency is valuable. And for something like struct Point { x, y int } there is no real confusion to writing Point{1, 2} Why make people always write Point(x: 1, y: 2} ? Also consider that there are useful structs with a single field, in order to implement some interface without allowing people to casually change the value. It would be a pain to force people to always state the field when writing a composite literal. And it would be a pain to have a special exception for a single field. 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. For more options, visit https://groups.google.com/d/optout.