keyed vs unkeyed fields

[Anmol Sethi]

Keyed fields seem to be always better than unkeyed fields in a composite literal.
Under what circumstances would I want to use unkeyed fields?

[Ian Lance Taylor]

On Fri, Aug 12, 2016 at 2:29 PM, Anmol Sethi <an...@aubble.com> 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?

Keys aren't always useful, e.g.,

var colors = [...]string{"red", "blue", "green", "yellow"}

Ian

[Anmol Sethi]

My bad. I should have specified that I meant struct literals.

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jesse McNelis]

On Sat, Aug 13, 2016 at 7:29 AM, Anmol Sethi <an...@aubble.com> 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.

[Nate Finch]

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.

[Anmol Sethi]

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?

[Ian Lance Taylor]

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

[Jonathan]

On Friday, August 12, 2016 at 5:31:07 PM UTC-4, Anmol Sethi 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?

When it's useful for writing code that is easier to read and comprehend. This is similar to using naked returns: some code can be made clearer using it; some code can be made more obscure.

I think most valuable use is for large compound literals, e.g. arrays of structs:  Key-less specification lets the element literals easier to scan; they occupy a narrower visual field.  The labels are redundant.

Jonathan