>From the blog post:
For example there could be an eq interface that’s equivalent to a contract
> with an x == x.
Actually, there can't. If eq were an interface, then
func f(x, y eq) bool { return x == y }
would be legal. And so would the call
var a int
var b float64
f(a, b)
since both int and float64 support ==.
The problem is that the spec says that the operands of == have to be the
same type, so this code is invalid.
It's hard to see how to fix the problem without changing something
fundamental about the language.
On Sunday, September 2, 2018 at 4:08:48 AM UTC-4, Charlton Trezevant wrote:
>
> Link: [Getting specific about generics, by Emily Maier](
> https://emilymaier.net/words/getting-specific-about-generics/)
>
> The interface-based alternative to contracts seems like such a natural
> fit- It’s simple, straightforward, and pragmatic. I value those aspects of
> Go’s philosophy and consider them to be features of the language, so it’s
> encouraging to see a solution that suits them so well. The author also does
> a great job of contextualizing the use cases and debate around generics,
> which I found incredibly helpful.
>
> Any thoughts?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
