Updated my comment.

Go2GenericsFeedback.md

@@ -167,7 +167,8 @@ Please format all entries as below.
 To make it easier to see new feedback. Please _make a Gist_. And also help to keep the list sorted in reverse-chronological order by including your new entry at the _top_ of the category list.
 
 ## Quick comments
-- [Chester Gould](https://github.com/Techser/): The only problem with this proposal is that explicit contracts seem to only make the code more verbose which is against the goal of simple readable code. Instead of writing explicit contracts, using the actual code we write as a kind of "implicit contract" would be much more simple and elegant. An example of this is shown [here](https://gist.github.com/Techser/72945cef3e5755d0ea0b8fd113fc25c7)
+- [Chester Gould](https://github.com/Techser/): The only problem with this proposal is that explicit contracts seem to only make the code more verbose which is against the goal of simple readable code. Instead of writing explicit contracts, using the actual code we write as a kind of "implicit contract" would be much more simple and elegant. An example of this is shown [here](https://gist.github.com/Techser/72945cef3e5755d0ea0b8fd113fc25c7). I acknowledge that this is addressed [here](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md#type-contracts), but I disagree that explicit contracts are the solution to problem. It seems to me that contracts are very close to what interfaces provide and so the behaviour of interfaces should be extended to allow behaviour closer to contracts rather than adding an entire new type of statement to the language.
+
 - [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!