composite literal uses unkeyed fields

[Harry]

Hi guys,

I've started to use go vet command recently.

After running, something error "composite literal uses unkeyed fields" was displayed.

Defined structure seem to be wrong.

What is that?

How can I manage to modify?

Thank you in advance.

[Tamás Gulácsi]

Add keys - for
type s struct{a,b int}
Instead of z :=s{1,2}
Use z :=s{a:1,b:2}

[Rob Pike]

The argument for the complaint is that keyed composite literals are more future-proof. If you later change the layout of s, the code will fail to compile if the keys no longer work, but an unkeyed literal may compile incorrectly. In your example, if you swapped a and b in s, the first assignment of z would set 1 to b and 2 to a.

It also affects guarantees of compatibility. See https://golang.org/doc/go1compat.

-rob

--
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.

[Harry]

Thank you for your help, I got it!

I'll always use keyed field if possible.

2016年1月7日木曜日 18時03分00秒 UTC+9 Harry:

[yuggu...@gmail.com]

Worked for me, Thanks!

[Space A.]

I'm using unkeyed fields for the opposite reason: I don't want code to compile when I add new fields to the struct, unless this is reflected at the other end. For example, I found it very useful sometimes, to pass a long list of arguments to the function through a struct. The same would happen if I pass arguments directly and change signature of the function by adding arguments, so the code won't compile if this function is still being called with lesser number of arguments. But it could compile incorrectly, if I just change the order of the arguments of the same type.

On Thursday, January 7, 2016 at 6:33:20 PM UTC+3, Rob 'Commander' Pike wrote:

The argument for the complaint is that keyed composite literals are more future-proof. If you later change the layout of s, the code will fail to compile if the keys no longer work, but an unkeyed literal may compile incorrectly. In your example, if you swapped a and b in s, the first assignment of z would set 1 to b and 2 to a.

It also affects guarantees of compatibility. See https://golang.org/doc/go1compat.

-rob

On Thu, Jan 7, 2016 at 2:21 AM, Tamás Gulácsi <tgula...@gmail.com> wrote:

Add keys - for
type s struct{a,b int}
Instead of z :=s{1,2}
Use z :=s{a:1,b:2}

--
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 golan...@googlegroups.com.