Sorry, I'm wrong about `eq`. It could be an interface, because `==` is
treated specially for interface types.
But you couldn't have an interface for any other operator, like `<` or `+`.
On Monday, September 10, 2018 at 9:55:04 AM UTC-4, Jonathan Amsterdam wrote:
>
> 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.
