Why does `slices.Clone` declare `[S ~[]E, E any]` instead of one `[E any]` with a `[]E` parameter?

## The two shapes Compare these declarations, both of which copy a slice: ```go func CloneE[E any](s []E) []E // one type parameter func Clone[S ~[]E, E any](s S) S // two, the first constrained by the second ``` The second is the shape the standard library's `slices` package uses throughout — `slices.Clone`, `slices.Sort`, `slices.Contains` and friends all begin `[S ~[]E, ...]`. It looks like ceremony until you see what it buys. ## What each parameter names In `[S ~[]E, E any]`: - `E` is the **element** type. `any` places no requirement on it. - `S` is the **slice** type the caller actually used. Its constraint, `~[]E`, is a type set: every type whose *underlying* type is `[]E`. That includes the slice type literal `[]E` itself and every defined type built on it. So for `type Names []string`, calling `Clone(Names{"a", "b"})` binds `S = Names` and `E = string`. The function's parameter is typed `S`, and — the point of the whole exercise — so is its result. ## One list, one scope Notice that `S`'s constraint refers to `E`, which is declared later in the same bracket list. That is legal, and it is a direct consequence of how type parameter scope works: **all the type parameters in one list are in scope across the entire list**, as well as across the rest of the signature and the body. Declaration order inside the brackets carries no meaning, and mutual references between constraints are permitted. Writing `[E any, S ~[]E]` compiles just as well; the `slices` convention of putting the slice type first is stylistic. ## What you lose with the single-parameter form It is tempting to conclude that `CloneE[E any](s []E) []E` simply cannot take a `Names`. It can: `Names` and `[]string` have identical underlying types and one of them is an unnamed type literal, so Go's assignability rules let a `Names` value be passed as a `[]string` argument, and let the returned `[]string` be assigned back into a `Names` variable. The loss is subtler and shows up in the **static type of the expression**: ```go type Names []string func (n Names) First() string { return n[0] } var n Names _ = Clone(n).First() // fine: Clone returns Names // _ = CloneE(n).First() // does not compile: CloneE returns []string, which has no methods ``` A `[]string` has no method set, so any method you declared on `Names` is unavailable on the result until you assign it to a variable of type `Names` or convert it. The same demotion propagates into further inference: passing `CloneE(n)` on to another generic function infers `[]string`, not `Names`. ## Where it also matters The pattern is not only about methods. Anywhere a function is expected to *return the type it was given* — a sort helper that returns the sorted slice, a filter, a deduplicator, a builder that chains — the two-parameter form preserves the caller's vocabulary. Functions that merely *consume* a slice and return something unrelated (a count, a bool, an index) gain much less from it; `slices` still uses the two-parameter form there for consistency of signature. ## Writing the body Inside the function, `S` behaves as a slice type: because every type in its type set has the same underlying slice type, `len`, indexing, `range`, `append` and `make` all work on an `S`: ```go func Clone[S ~[]E, E any](s S) S { out := make(S, len(s)) copy(out, s) return out } ``` `make(S, len(s))` produces a value of the caller's own slice type, which is exactly what the result type promises. Note that `copy` returns the number of elements copied, `min(len(dst), len(src))`, which here is `len(s)`. ## The cost The honest downside is readability. `[S ~[]E, E any]` is more to parse than `[E any]`, and a signature with three or four interdependent parameters gets hard to hold in your head. Reach for the second parameter when the function *returns* the collection type it was handed, or when a caller's named slice type carries methods that must survive. Otherwise the simpler declaration is the better one — and if the standard library already ships the helper, use that instead of writing either.