proposal: spec: require tagged literals for external structs

[robpike]

It would aid compatibility and evolution if a package writer knew that all clients
creating structs with types exported from the package use the form
  pkg.Struct{A: a, B: b}
rather than
  pkg.Struct{a, b}

It may be worth making this a language restriction

[rsc]

Comment 2:

Not before Go 2.

Labels changed: added priority-someday, removed priority-later.

[rsc]

Comment 3:

Labels changed: added repo-main.

[rsc]

Comment 4:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

[ianlancetaylor]

Comment 5:

Labels changed: added go2, removed priority-someday.

[ianlancetaylor]

At present there is a vet check for this:

> go vet
b.go:5:9: pkg.Struct composite literal uses unkeyed fields

Is there an advantage to promoting this check to the language level?

[griesemer]

There might be scenarios where it's tedious to have to repeat struct field names over and over again; e.g., for small structs that are frequently created and won't change. Example

p := graphic.Point3D{1, 2, 3}

But for cases like these it's always easy (and probably better) to provide any factory function instead.

[cristaloleg]

There is a trick to force users of an exported struct to write field names:

type Struct struct {
	A int
	B string
	_ struct{}
} 

And for any usage of Struct{1, "2"} a simple compile error will appear:

./prog.go:4:16: too few values in Struct literal (Playground https://play.golang.org/p/sPgtcxAoOxd)

(source: https://groups.google.com/forum/#!topic/golang-nuts/NSjVW82i0mY)

[ianlancetaylor]

As this is checked by vet today, it does not seem necessary to add to the language proper.

(Perhaps at some future point we should consider promoting some vet checks into the language proper.)