spec: should len(a) (and cap(a)) be constant for a of type parameter type constrained by same-size arrays?

[griesemer]

Reminder issue to consider this case. See also #42029 for background.

This can wait for 1.19 as going from a non-constant to a constant result for len and cap is a backward-compatible change (I think, since the type doesn't change, it's always int).

[griesemer]

Note that the spec currently says:

The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated.

If it said

The expressions len(s) and cap(s) are constants if s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated.

and we look at array (and pointer to array) as structural types, then we may need to make the result constant in some cases. The effect on real-life programs is negligible, this is mostly a spec precision issue.

In the implementation it would mean changing a call to under to structuralType.

cc: @ianlancetaylor

[go101]

Moving this to Go1.19 means it will be always as such. It is a problem same as aConstString[i:j].

[go101]

BTW, it looks it is disallowed to pass addresses of array type parameter values to len:

package main


func f[T [2]int]() {
	var x T
	const _ = len(&x) // invalid argument: &x (value of type *T) for len
	var _ = len(&x)   // invalid argument: &x (value of type *T) for len
}

func main() {
	type T [2]int
	var x T
	const _ = len(&x) // okay
}

[griesemer]

Too late for 1.21 if anything needs to be done here.

[griesemer]

Moving to 1.23. We're not going to change this for 1.22.