proposal: spec: make len(a), cap(a) const for some type parameters

[griesemer]

Proposal Details

The code

func _[A C](a A) {
   const _ = len(a) // or cap(a)
}

should be valid if the constraint C describes a type set containing only (pointer to) arrays and all arrays have the same length. Currently, the length and capacity of a type parameter value are always non-constant. Either way, the type is defined to be int per the spec. An int constant value can be used wherever an int non-constant value is permitted. Thus, this change is strictly backward-compatible; it simply increases the set of valid programs.

See also #50226.

[gopherbot]

Change https://go.dev/cl/562349 mentions this issue: go/types, types2: len/cap to be constant for certain array parameter values

[gopherbot]

Change https://go.dev/cl/562323 mentions this issue: spec: len/cap to be constant for certain type parameter values

[mdempsky]

Thus, this change is strictly backward-compatible; it simply increases the set of valid programs.

I believe this is a counter-example that would stop type-checking with this change:

func F[T *[0]int](x T) {
	switch 0 {
	case 0:
	case len(x):
	}
}

If we want to be strictly backwards-compatible, I think this semantic change needs to be tied to the language version like for loops.

[zigo101]

Bit-shift 1 << len(a) is also a blocker.

[griesemer]

@mdempsky Indeed. Seems pretty esoteric, but it would break such code. Maybe not worth making this change.
(More generally, the same spec trick can be used for any similar language change where we might go from a variable value to a constant value.)

[zigo101]

Similar to #28591

[zigo101]

Honestly speaking, the change is quite small comparing to the loop var change.

[rsc]

Since the change is not backwards compatible, it seems like we should leave things as they are.

[griesemer]

Retracting.

[rsc]

This proposal has been declined as infeasible.
— rsc for the proposal review group