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 e
also...if you want to get really specific...for float32 and float64, x==x
may not be true. (NaNs)
On Mon, Sep 10, 2018 at 7:02 AM Jonathan Amsterdam
wrote:
>
>> The problem is that the spec says that the operands of == have to be the
>> same type
>>
>
> Correction: one operand must be assignable
>
>
> The problem is that the spec says that the operands of == have to be the
> same type
>
Correction: one operand must be assignable to the type of the other.
The example still stands: you can't compare an int and a float64.
--
You received this message because you are subscribed to the
>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,
Great discussion, thanks for the comments! I wrote a bit more responding to
things I saw here and elsewhere:
https://emilymaier.net/words/another-generic-post/
Emily
On Sunday, September 2, 2018 at 4:08:48 AM UTC-4, Charlton Trezevant wrote:
>
> Link: [Getting specific about generics, by Emily
I do like using interfaces only, and having the language declare some
built-in ones and automatically map them to the operators. A problem is
that for consistency they should go both ways... and then you end up with
operator overloading which I've never been a fan of because people use it
to wr
On 02-09-2018, Tristan Colgate wrote:
> --633c2e0574df037c
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> It's a great read, clarified stuff for me. An approach that embraces
> interfaces feels preferable to me.
+1
--
William
--
You
