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.

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.

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)

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

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?

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

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?

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

Here’s a use case for this that I ran into just now:

myMap := map[string]any{}
if condition {
    myMap["foo"] = "bar"
} else {
    myMap["foo"] = "qux"
}

// This function takes a slice of maps; in our case, we only pass one.
DoThingWithDicts( ctx, slices.Of(myMap), "something else" )

Here, Of() alleviates an unergonomic duplication of map[string]any.

To sum up this proposal’s rationale: for the same reason why we all enjoy the freedom to write

foo := "bar"

… rather than

var foo string = bar

… it would be useful for Go to apply type inference to slice literals, e.g., foo := []{"bar", "baz"}. A proposal to implement this was declined, with a proposed alternative from @ianlancetaylor of creating slices.Of to achieve something comparable. (Arguably better, actually, since slice literals don’t currently allow unrolling, e.g., foo := []{"bar", others...}.

This issue basically just formalizes that slices.Of proposal.

(I should note that the original slices.Of proposal was pretty popular, with 9 thumbs-up and 0 thumbs-down.)