On: Deconstructing Go Type Parameters

[dolmen]

I have a question that this post doesn't answer: is the order of type parameters significant? Is there a canonical way, an idiomatic style for the order?

Example:

  func Clone1[S ~[]E, E any](s S) S {
    return append(s[:0:0], s...)
  }

vs

  func Clone2[E any, S ~[]E](s S) S {
    return append(s[:0:0], s...)
  }

[xh-dude → dolmen]

The logic for inferring types plays out better for the first. Go limits the depth of searching for type inferences, to keep compilation fast/small/simple. It’s always possible to be more explicit but nice to infer when calling generic code.

[xyzzy_plugh → dolmen]

Is the order of function parameters significant?

[dolmen → xyzzy_plugh]

Fair. Type parameters is significant when you call the function with explicit type parameters. Ex: clone1 := Clone1[[]string, string]

But when type parameters values are infered, the order looks much less important for the API designer.

Do we have rules (idioms) somewhere about a recommended order for such parameter types?