<p>One of the things I love about Golang is, actually, the lack of generics. Having a type for every variable and being bound to it just feels like you're writing higher quality code. There are times though where I'll be forced to do a type conversion and think what's the point, and how nice it would be to have truly mutable variables.</p>
<p>It seems there's two options that are being talked about; either have strict typing, or have generics. The proposals for generics too look more in the C++ fashion, whereas I'm thinking more JavaScript.</p>
<p>What if there could be a middle-ground?</p>
<p>I am by no means knowledgeable enough to comment on the inner working of Go or it's compiler or anything, but brainstorming, it would be pretty interesting to be able to define multiple types a variable could be. For instance, if a function needs to accept both an int and float32 value, you could define the parameter with these two possible types.</p>
<p>To do this, I'm not sure if anything would even need to be changed on the actual Go side of things (although I'm sure a standard implementation would be much better), but I believe this could be done as a kind of transpiler - Go code with multiple types is taken and transformed into standard Go code (multiple functions, etc).</p>
<p>Sometimes things are better explained with code:</p>
<p>What we have now (Ex #1): <a href="http://play.golang.org/p/Ofqmu7wEhM" rel="nofollow">http://play.golang.org/p/Ofqmu7wEhM</a></p>
<p>What KoG (Kind-of Generics) could look like (Ex #2): <a href="http://play.golang.org/p/30Jv8pSfL3" rel="nofollow">http://play.golang.org/p/30Jv8pSfL3</a></p>
<p>How the final transpiled Go code could look for Ex #2: <a href="http://play.golang.org/p/ZwDkeNoWIT" rel="nofollow">http://play.golang.org/p/ZwDkeNoWIT</a></p>
<p>Just thinking about it and I'm not proposing this as a change or anything, would just like to see what other people think.</p>
<hr/>**评论：**<br/><br/>shovelpost: <pre><p>If you <em>truly</em> need "Kind-of Generics" then use go generate. </p></pre>beeker1121: <pre><p>Haven't heard of go generate before, looks interesting - is it basically a way to include your own functions within the compiler, that you can call from your Go code? I'm not sure I fully understand it.</p></pre>shovelpost: <pre><p>You can read the basics <a href="https://blog.golang.org/generate" rel="nofollow">here</a>.</p></pre>beeker1121: <pre><p>Thanks, gonna check it out.</p></pre>interactiv_: <pre><p>C has void pointers, Go has interface {} . Go stdlib is full of interface {} in method signatures. You know what it's fine to use that. Go gen is just nasty and doesn't even solve the "generics" problem. Generics are a type you can pass to methods (in languages that support generics) , code generation doesn't add support for generics in Go. I don't believe text templating (because that's exactly what Go generate is about) produces higher quality code, because now you have to maintain the generator, the template and the pipeline to generate the code.</p>
<p>And you know what ? that's actually the job of a compiler at first place ! Now you get to write your own compilers because Go designers can't be bothered with that.</p></pre>barsonme: <pre><p>I prefer code generation, tbh.</p>
<p>The whole generation pipeline is fairly simple, especially for larger projects. For example, at work we will have a <code>make.go</code> file in the root directory that builds the entire app. Adding a generation phase is as easy as adding a new flag.</p>
<p>Plus, there's a handful of "generic" libraries out there that support code generation, so you don't have to maintain that either.</p>
<p>I dislike generics implemented with <code>interface{}</code> because generics you lose type safety. An <code>Add(X, y interface{}</code> function accepts strings and structs and slices as well as integer and floating point types.</p>
<p>This means either the function needs to return the value <em>and</em> an error, or it needs to panic on an invalid input. The former is annoying and the latter is a terrible programming practice</p></pre>interactiv_: <pre><p>i care about polymorphism more than I care about Go rigid type system. Code generation is not polymorphism.</p></pre>beeker1121: <pre><p>Good point, and if the text templating is something like how C++ handles generics, I completely agree that it seems backwards. If anything, generics imo would be better implemented either in partial as the KoG example, or like JavaScript.</p></pre>interactiv_: <pre><p>What they should have done, and it would have been a good compromise, is to allow "parametric" functions :</p>
<pre><code>func Foo<T>(arg1 T)T{ ... }
Foo<int>(3) // returns int
</code></pre>
<p>This way structs and co aren't affected, this is exactly how append works by the way, Go knows the return type of append, how ? I don't know, same with make. Why users are forced to use "void pointers" when go functions can do that is beyond me.</p>
<p>But it doesn't really matter, people have been arguing for years about the topic, nothing will be done about it, just use "interface {}" or "[]interface {}" and assert the resulting type of the value or the element of the slice. But don't use Go generate that's a mistake if your goal is clean code.</p></pre>mc_hammerd: <pre><p>agreed</p>
<p>i wrote a bash script to do just this; its a little inconvenient you have to save your go files as a diff extension (or foo_template.go) and use <code>//+build ignore</code>... then generate them. i had to learn awk and sed (from the 1970s!) to write it, it took a day but it worked really well.</p>
<p>i had planned to share my script but my hd exploded. <code>ginny</code> was the best go generate tool ive used; it does 100% what you need</p></pre>beeker1121: <pre><p>Pretty cool, thanks for the info.</p></pre>jasonMq: <pre><p>"Having a type for every variable and being bound to it just feels like you're writing higher quality code" ehh..nope..sorry I can't keep reading after that...</p></pre>beeker1121: <pre><p>Ultimately personal opinion, but I think a lot of people would agree with the statement.</p>
<ol>
<li>You as the programmer have to spend more time in the planning stages, so ideally more thought goes into your code.</li>
<li>In a statically typed language, more checks are performed by the compiler, resulting in more bugs found before they occur at runtime - better code.</li>
<li>Using static types saves on memory allocation.</li>
<li>No need to check for types by the compiler (or interpreter).</li>
</ol>
<p>I guess you could phrase it as 'writing better applications' if you want.</p></pre>
