<p>I work daily in Java (sad, but true), and appreciate there are some cases where generics are really handy. Most examples, to my eye, are sinful. Here are a couple sinful examples:</p>
<pre><code>Map<String, List<Map<String, String>>>
public class FiniteStateMachine<S extends Enum<S> & State, T extends Enum<T> & EventType, M extends EventMessage<T>, A extends ActionContext<S, T, M>>
</code></pre>
<p>I won't waste time explaining why/what I hate about those. I'm sure we can all mostly agree (given this is a go forum) that they are evil. (I realize that the first example can be replicated in Go with maps and slices, but I still think it's evil.)</p>
<p>In any case, it seems to me there are 2 cases in go where we might want to use generics:</p>
<ol>
<li>to define a "generic" struct/func that operates on an input "generic" item (and maybe returns it)</li>
<li>to define a "generic" struct/func that does no operations, but returns an input "generic" thing</li>
</ol>
<p>In case 1, the solution is to define an appropriate interface, and just use the interface in our new definition, and in our new methods. It's simple to define methods which return a defined interface type.</p>
<p>Case 2 is the only problem. When we want to handle/store/return a thing of any type, upon which we will do no operations. We do not want to use the empty interface, <code>interface{}</code>, and we want to declare a return type that the compiler can do something useful with.</p>
<p>So here is the proposal: Allow "generics" but only for a single level of type anonymity. The syntax might look something like this:</p>
<pre><code>func MyFunc(i int, thing *<Thing>) *<Thing> {
if i > 5 {
return thing
}
return nil
}
type MyThingContainer struct {
thing <Thing>
counter int
}
func MyThingContainer Get() <Thing> {
return thing
}
</code></pre>
<p>The main point is that generics are defined only a single level deep, and that it says nothing about any operations that may be performed on them. All it says is that you can receive and return a thing of any type, and that the type is preserved across that exchange.</p>
<p>In cases where it's necessary to build a complicated object like <code>Blaft<Glorp, Icker<Blaft<Glorp, Gaggle>>></code> each level would have it's own type definitions. Defining multilevel types would not be supported.</p>
<p>Are there strong reasons to support something more complicated that this?</p>
<hr/>**评论：**<br/><br/>devlambda: <pre><p>I think in order to have an in-depth debate about parametric polymorphism, it is a good idea to become familiar with not just the popular approaches used by Java and C++, but also with well-understood alternative forms. Most importantly:</p>
<ol>
<li>Modules parameterized by modules (ML functors, Ada generic packages, Modula-3 generic modules). Especially as they have a solid history in system programming languages.</li>
<li>Typeclasses (Haskell's version in particular). Note while they are popular in functional programming, they are not inherently tied to functional programming in any way, shape, or form.</li>
</ol>
<p>Java generics and C++ templates have very specific and idiosyncratic characteristics that one should not generalize for all kinds of parametric polymorphism.</p></pre>colezlaw: <pre><p>To extend the thought - those who day "Go lacks generics" already have a solution in mind without articulating the actual goal. After asking vendors for features for much of my career, I've learned to stop saying "it must be red, have four doors, four wheels, have a Max speed of 80mph, get 30mpg, and an automatic transmission" and rather to say "I need to get from New York to Los Angeles". Often, the vendor can give me a private jet, which is far better than what I had in mind. </p></pre>dlsniper: <pre><p>You can have a read here about generics in Go <a href="https://github.com/golang/go/issues/15292" rel="nofollow">https://github.com/golang/go/issues/15292</a></p>
<p>However, before jumping to the solution, make sure you define the problem, the examples show the problem (and are not forced to show it but rather they are natural, from code itself), think about solution and the ramifications of that solution.</p></pre>spaghettiCodeArtisan: <pre><blockquote>
<p>I won't waste time explaining why/what I hate about those.</p>
</blockquote>
<p>Why not? That would make it easier to think about how to fix them.</p>
<p>The first one, I'd say, is a pretty common example of lack of custom types. It could probably be fixed pretty easily by introducing one or few newtypes / custom classes.</p>
<p>The second one seems to be a generic type for an FSM. Defining FSMs generically is always going to be complex, that's not a problem with generics being complex but rather the problem itself being complex. People also use code generators to generate FMSs and they are complex too even when they use no generics. Also, the example is a generic definition, which is typically more complex than it's actual usage.</p>
<p>So, I guess the corollary is "not a problem with generics". Sure, the first one is needlessly nested, but then again you can needlessly nest functions or modules or other things as well. Not to mention that the first one can <em>already</em> be rewritten in Go verbatim :D</p>
<p>The second is pretty complex indeed, but that's not something that can be feasibly avoided IMHO other than by shifting the objective.</p></pre>grutoc: <pre><p>I don't need this, show me an example where I can't use an interface.</p></pre>StyMaar: <pre><p>Why this much zealotry against generics ? Of course you can use an interface but in many cases it's just a hack : it's not type-safe, it can't be optimized (monomorphization + inlining) then it has a performance overhead.</p>
<p>Generics are not more difficult to use than interfaces, it's just a better version of it most of the time. You should use generics almost all the time, and use interface only when you want type dynamism (you want to opt-out type-safety).</p></pre>forfunc: <pre><p>I think he means an interface not an interface{} </p></pre>thomasfr: <pre><p>I think that the most problematic thing about adding some kind of templates/polymorphic support is that it will be overused when interfaces (not emtpy ones) are good enough or better. Especially by people coming from C++-like languages.</p>
<p>And it's not hard at all to show examples since there is a very good recent one in the standard library now: <code>sync.Map</code>.</p></pre>bascule: <pre><p><code>sync.Map</code> uses <code>interface{}</code> for all keys and values and is not type safe:</p>
<p><a href="https://github.com/golang/go/blob/master/src/sync/map.go" rel="nofollow">https://github.com/golang/go/blob/master/src/sync/map.go</a></p></pre>thomasfr: <pre><p>Exactly, that was my point.. sync.Map is a great example of where some kind of templates-like feature would be useful. </p>
<p>Rather than having "generics" in the compiler I would be interested in more exploration of go generate first. </p>
<p>One exmple which I don't know if anyone has explored is an <code>eg</code> like tool for go generate which instead of doing an in place refactoring copies an implementation changing it's types or something based on example code.. You could then have <code>syncmap_generate.go</code> or something which contains some example code which copies and transforms the original source. I can't say I have thought about all the potential pitfalls of this yet but one of them is probably types/members private to another package.</p>
<p>As long as something ends up inside the go tool chain at some point I will be happy, it doesn't have to be compile time as long as it can be statically verified in some way.. </p></pre>grutoc: <pre><p>I don't use <code>interface{}</code> either, deal with it.</p></pre>gott_modus: <pre><p>why not just write in c then, man.</p></pre>grutoc: <pre><p>because it's shit?</p></pre>gott_modus: <pre><p>what makes it so shit</p></pre>grutoc: <pre><p>It blows in your face before you know it every single time.</p></pre>gott_modus: <pre><p>you're gonna have to bring forth more than that, man. generally speaking, making the claim that something is "shit" warrants some concrete evidence of shittyness. </p></pre>thomasfr: <pre><p>Does that mean that you never use <code>fmt.Sprintf</code>, <code>json.Unmarshal</code>, ..., ...? <code>interface{}</code> is very useful in the right places.</p></pre>grutoc: <pre><p>Go is so unique and it dosen't have Generics, I fear it will mass destroy the language, my only argument.</p></pre>Sythe2o0: <pre><p><a href="https://github.com/emirpasic/gods" rel="nofollow">https://github.com/emirpasic/gods</a></p></pre>grutoc: <pre><p>Damn it, already forgot all this crap...</p></pre>Hauleth: <pre><p><code>Min</code> and <code>Max</code> functions. </p></pre>CountyMcCounterson: <pre><p>What's wrong with being able to pass a string to a math function and have it be assumed to be an integer? I see no problem there.</p></pre>Killing_Spark: <pre><p>Well on strings that only contain ascii its fairly ok to do so, but then there are those asian fuck tons of characters :D</p></pre>thomasfr: <pre><p>I rather handle parsing and math separately because of what happens when the
assumption fails or what the returned type might be.</p>
<p><code>value:=Max("asdf")</code>: If there is only one return value this has to panic which
is very special case usage which can be implemented in application code when
and if it's needed.</p>
<p><code>value, err := Max("3.14")</code>: The type of <code>value</code> cannot be statically inferred
because it can be either an int or float.</p>
<p>IMHO both of those examples shows that it's easier to handle number parsing and
max'ing in separate steps in your program because otherwise would have to keep
track of too many permutations of Max behavior.</p></pre>gott_modus: <pre><p>why not just write in c then, man.</p></pre>_axelp_: <pre><p>And honestly, the same thing should be said of ints to string functions. Something that REALLY irks me in python is the fact that I can't do</p>
<pre><code>i = 2
s = "This is Python version "
print s + i
</code></pre>
<p>But rather I have to </p>
<pre><code>print s + str(i)
</code></pre>
<p>(or format or printf), but I still can't see why integers (or anything with __str__) can't be passed to print</p></pre>thomasfr: <pre><p>I would probably not be using python if + was supported like that.. It's just an endless source of bugs everywhere when things like that is allowed</p>
<p>You still have several string printing functions to choose from which does the job just fine like <code>print("{}{}".format("string", 123)))</code> </p></pre>_axelp_: <pre><p>I do use format() for most things, but it's a little annoying</p>
<p>I can see where some confusion may be initially seen from it, but after you learn about it could be easily adopted. I don't see how any interpretation from str+int could be seen <strong>unless</strong> it's a str of "5" + 3 which then you could as should it return int(8), str(8), str("5 + 3"), or str("53") but I think if you could adopt an official stance it would be beneficail</p></pre>thomasfr: <pre><p>For me it's not so much about confusion, primarily it's about security and identifying bugs.. I want my code to fail as early as possible if a string by accident or malice has made it's way into some number computation code.</p></pre>_axelp_: <pre><p>Ah I didn't think about security, but I don't think I wrote my last comment right. Strings would <strong>never</strong> be converted to ints (I agree with that!!), but rather ints would be converted to strings when in a print (or other output) function.</p>
<p>Something close to:</p>
<pre><code>def print(*args):
final_str = ""
for arg in args:
if not isinstance(arg, str):
try:
final_str+=arg.__str__
except:
pass
else:
final_str+=arg
return final_str
</code></pre>
<p>Or something</p></pre>Poddster: <pre><blockquote>
<pre><code>print s + int(i)
</code></pre>
</blockquote>
<p>You mean:</p>
<pre><code>print s + str(i)
</code></pre></pre>wicked-canid: <pre><blockquote>
<p>but I still can't see why integers (or anything with __str__) can't be passed to print</p>
</blockquote>
<p>They can, but that's not what you're doing here: you're adding a string to an int, the print has nothing to do with it. </p></pre>_axelp_: <pre><p>You're totally right! I don't know what I was thinking :)</p></pre>
