proposal: slices: add Of function

[FGasper]

In #47709 it was proposed to add type inference for slice literals, e.g., foo := []{"bar", "baz"}. That proposal was declined in favour of creating an equivalent function in slices.

This issue proposes a slices.Of(…) method to do that, e.g.:

foo := slices.Of("bar", "baz")

… would be equivalent to:

foo := []string{"bar", "baz"}

The benefit is minimal in a trivial case like the above, but to create a slice of *somepackage.NameThatIsRatherLong it would be helpful.

[ianlancetaylor]

As you say, I can't see anybody using this rather than []string{}. It would help to point to some existing code that would benefit from changing to slices.Of. Thanks.

[zephyrtronium]

The benefit is minimal in a trivial case like the above, but to create a slice of *somepackage.NameThatIsRatherLong it would be helpful.

I would argue the opposite: you would have to write

slices.Of(&somepackage.NameThatIsRatherLong{...}, &somepackage.NameThatIsRatherLong{...})

when you could just write

[]*somepackage.NameThatIsRatherLong{{...}, {...}}

Compared to writing a slice literal, slices.Of would only ever have the advantage of inferring the element type from arguments. That seems only useful when the element type is the default type of untyped constants, as in the original example with strings, or when the element type cannot be named e.g. due to being unexported. Maybe it could save some typing when combined with type inference on assignments from functions as well.

[FGasper]

Maybe it could save some typing when combined with type inference on assignments from functions as well.

Right, something like:

foo := returnsInstanceOfUglyLongName(alpha)
bar := returnsInstanceOfUglyLongName(beta)

metaVars := slices.Of(foo, bar)

[FGasper]

@Nasfame: I’m envisioning its being as simple as:

func Of[T any](pieces ...T) []T {
	return pieces
}

So nos here would be of type []newInt.

As to performance: I don’t know Go internals well enough to speculate competently, but I would think the function call to be less performant than a slice literal. Of course, if Of() proves popular enough, that may speak in favour of making it a language-native feature.

[ianlancetaylor]

Note that that suggested implementation means that

    a := []int{1, 2, 3}
    b := slices.Of(a...)
    a[0] = 4
    fmt.Println(b[0])

will print 4. Anybody have an opinion on whether that will be confusing?

[bcmills]

I think that would be confusing. I would implement it as:

func Of[T any](pieces ...T) []T {
	return append([]T(nil), pieces...)
}

and trust (or improve) the compiler to eliminate the intermediate argument slice when it isn't needed.

[Edited to add the explicitly-typed nil that is required today.]

[FGasper]

I’m probably just missing something, but that seems to contradict the specification:

… the value passed is a new slice of type []T with a new underlying array whose successive elements are the actual arguments …

If b has a new array, why would assigning to a[0] affect b?

[ianlancetaylor]

@FGasper Read a few lines down.

If the final argument is assignable to a slice type []T and is followed by ..., it is passed unchanged as the value for a ...T parameter. In this case no new slice is created.