proposal: spec: permit conversion of []A to []B if A and B have same underlying type modulo struct tags

[adonovan]

Background: It is not uncommon to need to convert a value of slice type []A to type []B, where A and B have the same representation (e.g. string). Unfortunately, one must allocate a copy.

Proposal: We propose to relax the restrictions so that, given var ( a A; aa []A; b B; bb []B), the conversion ([]B)(aa) is legal so long as both B(a) and A(b) are legal A and B have the same underlying type, ignoring struct tags. The result would be a slice of the same len, cap, and pointer, but a different type. In other words, the operation creates an alias, it does not allocate an array.

The requirement for the mutual assignability same underlying type is that if aa aliases bb, then assigning to aa[0] and reading from bb[0] effects a conversion from A to B, and vice versa. Therefore both conversions had better be legal. Consequently, the two types must have the same memory layout (among other requirements).

[Edited: I mistakenly started with "mutually convertible" but this is not sufficient for e.g. A=float32 B=float64.]

Prior art:

• language: support explicit conversion from []A to []B if A is assignable to B #3756 - closed because it allowed []X->[]Y if X assignable to Y (which may change repr + allocate)
• proposal: spec: relax structural matching for conversions #19778 - similar but requires "same memory layout", which is not a spec concept
• Allow type conversion of slices of same underlying types #29864 - closed by fiat

Loosely related:

• proposal: slices: convert one slice to another #64742: generic slice conversion, requires a func(X)Y operator though.
• proposal: spec: allow assignment-compatible values in append and copy #15209: generalize append/copy to permit assignment conversions

@ianlancetaylor @griesemer

[ianlancetaylor]

If we permit conversions between []A and []B when A(b) is valid, that implies that this conversion copies the slice. For consistency, we would want to also copy the slice if A and B have the same underlying type.

I believe this would be the first language operation that has unbounded execution time, since it depend on the length of the slice.

[adonovan]

To be clear: by mutually convertible I meant that A->B and B->A must both be valid conversions. The intent is that this operation creates an alias, and never allocates memory.

[Jorropo]

float32 → float64 is valid, so is float64 → float32
Yet I do not see any reasonable (aka without introducing dynamic tying to everything) way to implement the following code in constant time using aliases:

func f(x []float32) []float64 { return []float64(x) }

same for differently sized integers, floats ←→ integers, ...

what am I missing ?

Edit:
This part tries address this

Consequently, the two types must have the same memory layout (among other requirements).

But I think it's unclear for []float64 ←→ []uint64. It seems to me like we need a formal « same underlying bit representation » and only {,u}int{,64,32,16,8} would end up working ?
And everything based on the same underlying type.

[ianlancetaylor]

@adonovan Thanks. Apologies for misunderstanding.

[ianlancetaylor]

Agreed, I think mutual convertibility is not enough. I think we need to say that the underlying type is the same. (We could perhaps add some special language about channels, if we care.)

[jimmyfrasche]

Another case where one would want something similar is, for example, converting a []fmt.Stringer to an []any. That's not mutually convertible so only one direction makes sense but, when it does make sense, the source and target do have the same representation so it could be aliased without a copy.

[gabyhelp]

Related Issues

• proposal: spec: relax structural matching for conversions #19778
• language: support explicit conversion from []A to []B if A is assignable to B #3756 (closed)
• proposal: spec: allow slice-to-array conversion expressions to present as L-values. #47987 (closed)
• proposal: slices: convert one slice to another #64742 (closed)
• proposal: Go 2: spec: allow conversion from *T to *[1]T #45545 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[jimmyfrasche]

Since this came up in #69264, I'll use my example from there. In that I asked whether

func Mean(x []float64) float64

should be

func Mean[Slice ~[]E, E ~float64](x Slice) E

so that if you had a slice of type []Temp where type Temp float64 you could use it directly.

This proposal allows the API without generics to avoid a copy by allowing:

var temps []Temp = f()
tbar := Mean([]float64(temps))

But that doesn't do quite the same thing as the generic version which returns a value of type Temp so you'd need to write

Temp(Mean([]float64(temps)))

Further the generics version would accept a value with a type like type Temps []Temp and return a Temp. Would you be able to use that last line to do that or would it require another conversion first like:

Temp(Mean([]float64([]Temp(temps))))

?

If it were instead some function F that takes and returns a slice would it be

Temps([]Temp(F([]float64([]Temp(temps)))))
// or
Temps(F([]float64(temps)))

?

This would be a useful change but I don't know if it makes API design as nice and simple as one would hope so much as push it down the road.