proposal: spec: generic parameterization of array sizes

[ajwerner]

See detailed design here. The recent acceptance of #43651, we can now begin discussing filling in the gaps and omissions of that proposal. This issue provides a proposal to fulfill the following stated omission in the type parameter proposal:

No parameterization on non-type values such as constants. This arises most obviously for arrays, where it might sometimes be convenient to write type Matrix[n int] [n][n]float64. It might also sometimes be useful to specify significant values for a container type, such as a default value for elements.

The structure of the proposal boils down to two extensions:

1. Expression of all array types inside of type lists

Today one can specify a type constraint that a type is an array of some specific, constant size. For example:

type Array8[T any] interface {
    type [8]T
}

Similarly one can enumerate a set of array sizes:

type ArraysOfSomeSizes[T any] interface {
    type [2]T, [4]T, [8]T, [16]T
}

But, there's no way to capture the idea of all arrays of a given type. This proposal proposes the following syntax to capture that idea:

type Array[T any] interface {
    type [...]T
}

This syntax is familiar as it is used for length inference in array literals.

2. Permit constant expressions to determine the length of an array type using len([...]T)

I'm not wedded in any way to the function with this behavior actually being len. It could be some
new thing like ArrayLen([...]T) in some package somewhere.

Today go provides both constant expressions which take types (see unsafe.Sizeof) and more generally
builtin functions which take types. Secondly, the go compiler already statically computes array lengths
at compile time when it can.

Constant expressions can be already be used to size arrays.

Taken together, one can imagine using this constant expression over some parameterized array type to
size other array types.

A detailed discussion with examples, background and motivation can be found in this proposal.

[ianlancetaylor]

Thanks. I'm not quite sure about the constant expression bit; it's important to not constrain the compiler implementation. In any case I think we have our hands full with the current proposal. I'm going to put this on hold for now for consideration as a future language extension.

[ajwerner]

Thanks for giving it a look.

I'm not quite sure about the constant expression bit; it's important to not constrain the compiler implementation.

Look forward to working out the implications here for the compiler when the time comes. Will give it a rest for 6-9mo and see how the rest of the type parameter implementation shakes out.

[gopherbot]

Change https://golang.org/cl/301290 mentions this issue: Add proposal for parameterized generic array sizes

[rogpeppe]

A few thoughts:

• I came up with the exact same [...]T notation independently, which seems like a reasonable indicator that it's a natural fit.
• there's no need for a new len([...]T) syntax: len(T{}) is already valid and sufficient (as is len((*T)(nil))). In general, len takes a value expression, not a type expression, so I think that's fine.
• I don't think that making len(T{}) into a const expression will constrain the compiler implementation. The generated code already needs to know the sizes of all type parameters so it can compute field and slice offsets, and I don't think this is any different.

With regard to the last point, I don't see a huge difference between:

type Array[T any] interface {
	[...]T
}
func concatArrays[T any, A, B Array[T]](a A, b B) [len(A{}) + len(B{})]T {
	var r[len(A{}] + len(B{})]T
	copy(r[:], a[:])
	copy(r[len(a):], b[:])
	return r
}

and:

func mkPair[A, B any](a A, b B) struct{T0 A; T1 B} {
	return struct{T0 A; T1 B}{
		T0: a,
		T1: b,
	}
}

They're both forming a new type with a size dependent on the sizes of two type parameters.

The main thing that concerns me about this proposal is that there is considerable potential for code bloat if the feature is used a lot, particularly if the stenciling or GC stenciling implementation approach is used. But there's also potential for the same kind of issue even without generic arrays so maybe that's not a good argument.

It's just a bit easier with arrays. For example:

const n = 1<<30

func F[T interface {[...]byte}]() int {
	if len(T{}) >= n {
		return len(T{})
	}
	return F[[len(T{})+1]byte]()
}

That particular kind of abuse could be avoided by prohibiting recursive generic functions where the type parameters of the recursive call aren't identical. I haven't yet seen a good use case for allowing that yet, and it avoids a bunch of potential problems.

In general, I'm +1 on this proposal as long as we can be happy that it's not open to serious abuse (e.g. computation in the type system).