cmd/compile: cannot index pointer to generic array

[josharian]

This does not compile:

package p

type a1 [16]byte
type a2 [32]byte

type A interface {
	a1 | a2
}

func elem0[T A](t *T) *byte {
	return &t[0]
}

Error: ./x.go:11:10: invalid operation: cannot index t (variable of type *T)

This shows up in practice if you want to embed an array in a generic struct to avoid extra indirection/allocs, like this:

type S struct {
  // other fields
  arr A
}

but pass pointers to the array around internally to avoid making lots of copies of it (particularly as the array gets large).

The equivalent non-generic code compiles:

func elem0concrete(t *a1) *byte {
	return &t[0]
}

[ianlancetaylor]

CC @griesemer @findleyr

I think this may be expected at present.

[griesemer]

This is currently as expected. Note that the existing rules in the spec require a pointer to an array. Expanding this to type parameters requires that we have pointers to arrays in the type parameter type set (which is accepted). We'd need a new rule to generalize this also across a type parameter boundary. I'm not saying we can't do that, but it's an exception to the otherwise relatively regular rules.

This works:

package p

type a1 [16]byte
type a2 [32]byte

type A interface {
	*a1 | *a2
}

func elem0[T A](t T) *byte {
	return &t[0]
}

is that not sufficient?

[josharian]

is that not sufficient?

This is what I mentioned above about embedding an array in a generic struct to avoid extra indirections and allocs. struct { x [16]byte } is importantly different than struct { x *[16]byte }.

(But maybe I'm missing something. I find I still do not yet know how to make good use of generics.)

[ianlancetaylor]

Can you show us more context? Show us the program that doesn't work with @griesemer 's suggestion.

[josharian]

In the course of writing a minimized program, I found a workaround:

func elem0[T A](t *T) *byte {
	switch a := any(t).(type) {
	case *a1:
		return &a[0]
	case *a2:
		return &a[0]
	default:
		panic("unreachable")
	}
}

It's ugly, but it works.

[findleyr]

Just catching up and curious about this.

@josharian why is that type switch necessary? Why can't you use @griesemer's suggestion of including the pointer-to-array types in the type parameter type set?

type A interface {
	*a1 | *a2
}

func elem0[T A](t T) *byte {
	return &t[0]
}

But also, @griesemer I'm not sure that supporting this would make the spec less regular, and supporting this seems straightforward (I have a CL that does it...). I actually think that @josharian demonstrated that it would be less surprising if this worked, than if it doesn't.

[griesemer]

I agree that supporting it is straight-forward. But we need an extra rule. We may also need to look into other situations where we may need to apply this (pointer-to-struct in some cases).

[findleyr]

Ok, thought about this a bit more. I think it may more generally be a source of confusion that type expressions do not 'map over' type sets; i.e. the type set of *T is not "the set of pointers to types in the type set of T", but rather a single type. This is why some of the places where type substitution would work are disallowed by the type checker. I understand the reasons for this (I think). However, I expect that most users will not memorize all the rules for type parameters, and will instead apply the 'substitution' heuristic. Anything we can do to align the spec more closely to the substitution heuristic may actually reduce user confusion, even if it complicates the spec.

But I don't think anything needs to be done for 1.18. I'll re-close this issue again and we can revisit if there is further confusion of this sort.

I would still be interested in @josharian's use-case though.