Updated Go2GenericsFeedback (markdown)

Go2GenericsFeedback.md

@@ -154,6 +154,8 @@ To make it easier to see new feedback. Please _make a Gist_. And also help to ke
 
 ## Quick comments
 
+- [Izaak Weiss](https://github.com/lalaithion): A lot of the discussion has focused specifically on how to implement contracts, or something like that. However, most of the "useful examples" don't require contracts; they only require parametric polymorphism. Writing a typesafe `Merge` or `SortSlice` is possible without contracts. And for the simpler contracts, we can implement them via higher order functions. A generic hashmap can be parametric over a type with a `Hash` method, or it can take a `func(K) int64` when it is constructed, and use that to hash its keys. If more functions are required, structs holding these functions can be declared as pseudo-contracts, and then those can be passed to the generic function. This makes Go's polymorphism simple, explicit, and leaves room for further innovation regarding contracts or other mechanisms in the future, while allowing most of the benefits of generic types to be realized right now.
+
 - [Christoph Hack](https://github.com/tux21b): I just watched Alexandrescu's last talk [The next big Thing](https://www.youtube.com/watch?v=tcyb1lpEHm0). He states "Concepts are a waste of time" and proposes a completely different, far more powerful, direction (even in comparison to everything possible in C++ today). Go already has most required features, like reflection and testing if a type implements an optional interface. The only thing missing is code generation. For example, ``json.Marshal`` works fine by using reflection, but if it could also (optionally) generate code by implementing a Go function that gets called by the compiler automatically and runs regular Go code, we would have everything. It might sound crazy at first and toy examples might look verbose, but I think Alexandrescu has a point there. Just think about gqlgen vs. the other reflection based graphql-libs for example. Please watch his talk!
 
 - [Bodie Solomon](https://github.com/binary132): I find the generics design a bit confusing and opaque. Please consider integrating some concepts from [Zig's beautiful comptime functions](https://news.ycombinator.com/item?id=13761571)! The design of Go 2 generics is clever, but I feel it goes against Go's traditional tight coupling between simple runtime semantics and simple syntax. Additionally, one of the biggest problems of Go, which prevents it from being a viable competitor everywhere I might like to use it, is that I cannot be rid of the GC and runtime. It was my strong hope that Go 2 would introduce compile-time-only generics such that I could reliably avoid the use of dynamic interfaces where I don't want them, without relying on codegen. Unfortunately it looks like that will be decided by the compiler without my input. Please, at least, consider giving users the ability to constrain generics to compile-time-only resolution, perhaps as a property of a Contract, rejecting compilation of dynamic types to satisfy the contract.