spec: the prose for the special case for append could be clearer

[griesemer]

Follow-up on #76220:

Per the spec:

The variadic function append appends zero or more values x to a slice s of type S and returns the resulting slice, also of type S. The values x are passed to a parameter of type ...E where E is the element type of S and the respective parameter passing rules apply. As a special case, append also accepts a first argument assignable to type []byte with a second argument of string type followed by .... This form appends the bytes of the string.

Note that the special case prose doesn't necessarily imply that the first argument must be a slice. In particular, it could be nil because nil is assignable to []byte, yet that never was permitted in the implementation.

Should be more precise in prose.

[gabyhelp]

Related Issues

• spec: clarify type signature of append #1717 (closed)
• proposal: spec: allow append(string, ...) and view the string argument as a byte slice #43429 (closed)
• the builtin function `append` annotations looks like should be updated #48089 (closed)
• spec: several sections require core types and don't mention `[]byte | string` #52859 (closed)
• spec: clarify that append will only replace the slice if the capacity is not large enough #5180 (closed)
• proposal: Go 2: spec: remove special cases for strings in conversions, append, and copy #24529 (closed)
• Function documentation for builtin 'append' doesn't mention append([]byte, "string"...) #4873 (closed)
• go spec: language for append() built-in is contradictory #1936 (closed)

Related Code Changes

• spec: document operations which accept []byte|string constrained types
• builtin: remove confusing mention of special case in append annotation

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/718880 mentions this issue: spec: more precise prose for special case of append

[jfrech]

I guess the present formulation should be read as:

(...) to a slices s (...) As a special case, append also accepts a first argument [s, which still is a slice,] assignable to []byte (...)

Note that the compiler diagnostics do talk about the requirement that s be a slice:

// https://go.dev/play/p/GGFBMdknJm8
package main

func main() {
	_ = append(nil, "")
}

// Output:
// ./prog.go:4:13: invalid append: argument must be a slice; have untyped nil

[jfrech]

Then again, it ices when you add ...:

// https://go.dev/play/p/qllCIEu1GjS
package main

func main() {
	_ = append(nil, ""...)
}

// Output:
// <unknown line number>: internal compiler error: panic: cmd/compile/internal/types2/builtins.go:1093: assertion failed
//
// Please file a bug report including a short program that triggers the error.
// https://go.dev/issue/new

[griesemer]

@jfrech Yes, I believe it's "obvious" to experienced Go programmers that the first argument must always be a slice. But a naive reader might just look at the special case, and the special case appears to a allow nil (implicitly). The spec change is minor, and simply there to make an incorrect reading - however unlikely - impossible.

Regarding the panic, see: #76220

[jfrech]

Fully agree; I'm in favour of clarifying the spec. I only wanted to make the case that the paragraph truly can be read in a way that matches the clarified version, if one makes the leap that the "first argument" still refers back to the first sentence's s.

Regarding the panic, I unfortunately read the two issues in the wrong order. Sorry for spamming.