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.
