Deconstructing Go Type Parameters

It really doesn&#x27;t help that the major (perhaps only?) official resources on generics in golang are these blog posts [1][2] and the spec. And now this blog post.<p>The whole &quot;what type am I getting&quot;&#x2F;make()ing is really tricky (as outlined in this doc) especially when its a pointer&#x2F;interface&#x2F;slice&#x2F;etc. And a lot of feels like it doesn&#x27;t need to be as much of a complex decision tree as it is. Is there any other documentation on this stuff that I&#x27;m missing?<p>Theres a lot of complication buried in golang people don&#x27;t talk about that much. nil vs empty slices, interface{} and any behavior differences, make() and what it would do for various type scenarios, impossible to remember channel semantics (which ones panic again?). Of course, theres always a good explanation for why it is the way it is, but for a language so opinionated, stronger opinions on better DX in the deeper parts would be great.<p>[1] <a href="https:&#x2F;&#x2F;go.dev&#x2F;blog&#x2F;intro-generics" rel="nofollow noreferrer">https:&#x2F;&#x2F;go.dev&#x2F;blog&#x2F;intro-generics</a> [2] <a href="https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;tutorial&#x2F;generics" rel="nofollow noreferrer">https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;tutorial&#x2F;generics</a>

I am a Go fan and have been coding in it for years, but this crap:<p>func Clone[S ~[]E, E any](s S) S { return append(s[:0:0], s...) }<p>looks just like Rust, which has the fugliest syntax I have ever seen. Personally I use maybe 3 or 4 generic functions to work with arrays(oh, sorry SLICES), otherwise I do not touch them. Could not care less about them and all that noise they caused.

I suppose this is necessary because this:<p><pre><code> func clone[S ~[]any)(s S) S </code></pre> would only allow things with an underlying type of []interface{}, not &quot;any type&quot; as an inferred type... and that applies to the final example too:<p><pre><code> &#x2F;&#x2F; allows any collection of stringable things func WithStrings[S ~[]E, E interface { String() string }]( &#x2F;&#x2F; allows only things like: &#x2F;&#x2F; []interface { String() string }{...} &#x2F;&#x2F; and named types like that, but not: &#x2F;&#x2F; []strings.Builder{...} &#x2F;&#x2F; because that isn&#x27;t the same collection type, &#x2F;&#x2F; it&#x27;s just a collection of compatible elements func WithStrings[S ~[]interface { String() string }](...) </code></pre> I guess this is the price to pay to avoid introducing co&#x2F;contra variance? It may be worth it, and it seems likely that it would be a thing you can improve without breaking compatibility.

Wow, I&#x27;m not super happy about the syntax of this language. I&#x27;m familiar with what each paragraph is describing from multiple other languages, but I can&#x27;t even <i>guess</i> how some of the syntax here maps onto those other languages, even with the explanations.

I’m almost a grey beard in typed functional programming and I’m actually confused by this.

I&#x27;m not sure I&#x27;m following the preamble about the nuances of a slice with a zero capacity allocating a new backing array, given the fact that if I follow the link to the docs and then to the source, the implementation is exactly how I would have expected it to be done: append(S([]E{}), s...) - which of course is different and would make the preamble redundant.

I have a question that this post doesn&#x27;t answer: is the order of type parameters significant? Is there a canonical way, an idiomatic style for the order?<p>Example:<p><pre><code> func Clone1[S ~[]E, E any](s S) S { return append(s[:0:0], s...) } </code></pre> vs<p><pre><code> func Clone2[E any, S ~[]E](s S) S { return append(s[:0:0], s...) }</code></pre>