An implicit equality typeclass instance, 2015: implicit val intEqual: Eq[Int] = new Eq[Int] { def equal(x: Int, y: Int): Boolean = x == y } (1/8)
-
Show this thread
-
SAM types introduced, 2016: implicit val intEqual: Eq[Int] = (x: Int, y: Int) => x == y (2/8)
1 reply 0 retweets 2 likesShow this thread -
Type inference improves, 2017: implicit val intEq: Eq[Int] = (x, y) => x == y (3/8)
1 reply 0 retweets 2 likesShow this thread -
Developers get lazier, 2018: implicit val intEq: Eq[Int] = _ == _ (4/8)
1 reply 1 retweet 4 likesShow this thread -
Some forgotten experiments, 2019: witness intEq: Eq[Int] = _ == _ (5/8)
1 reply 0 retweets 3 likesShow this thread -
We settle on `given`, 2020: given intEq: Eq[Int] = _ == _ (6/8)
1 reply 0 retweets 3 likesShow this thread -
Scala 3.0, 2021: given Eq[Int] = _ == _ (7/8)
3 replies 2 retweets 21 likesShow this thread -
Replying to @propensive
Lovely to see the noise of the unneeded `intEq` name going away there
1 reply 0 retweets 4 likes -
Replying to @rtyley @propensive
You're still gonna need it in situations like //dumb examples but you get the idea given [A: Eq]: Monoid[List[A]] given [A: Semigroup]: Monoid[List[A]] because the generated name is going to be the same (Monoid_List_A or something like that) but in 90%+ cases it'll be
1 reply 0 retweets 3 likes
I encountered this just today...
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.