CC @griesemer @findleyr

I think this may be expected at present.

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?

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.)

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

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.

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.

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).

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.

The use case is a trie for looking up IP addresses (without zones). For space reasons, it'd be nice to have an IPv4 trie [4]byte and an IPv6 trie [16]byte. Generics seemed like an obvious fit. This is performance sensitive, so it is important that the array be a struct field, rather than a pointer to an array (data locality, fewer allocs, no nil checks).

I was definitely using the mental heuristic you indicated.

I also just encountered an identical issue with slicing:

func asSlice[T A](t T) []byte {
	return t[:]
}

also does not compile, even though it compiles for each of the types in T.

Here's a more complete program:

package p

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

type A interface {
	a1 | a2
}

type S[T A] struct {
	arr T // initial backing array for buf
	buf []byte
}

func makeT[T A]() *S[T] {
	var s S[T]
	switch a := any(s.arr).(type) {
	case a1:
		s.buf = a[:]
	case a2:
		s.buf = a[:]
	default:
		panic("unreachable")
	}
	return &s
}

It'd be nice to be able to remove the dynamic type switch from makeT and just unilaterally write s.buf = a[:].

Note that defining T as *a1 | *a2 doesn't make any sense: The T field exists to provide an initial backing array, which is pointless if you have to allocate separately in order to use it.