3 ms·

So, they removed implicits and introduced a number of other tools to replace common usecases for implicits. Can we take a step back now, and reflect on what wa

by sesm 5y ago

So, they removed implicits and introduced a number of other tools to replace common usecases for implicits. Can we take a step back now, and reflect on what was the original problem implicits were designed to solve and how it is solved now in Scala 3? I've heard the original problem was that they wanted a chain of functional transformations to return the same type of collection (unlike, say, Clojure or Java 9 which return a Stream).

amw-zero 5y ago
I still don't fully understand it, but they wrote a lot about the topic here: https://dotty.epfl.ch/docs/reference/contextual/motivation.html https://dotty.epfl.ch/docs/reference/contextual/motivation.h...
halfmatthalfcat 5y ago
They didn't "remove" implicits in the absolute sense but they made it much more ergonomic to work with implicit-like behavior using the "given" keyword now.
- sesm 5y ago
  Sorry, maybe I was wrong. I was looking at this article https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html and I had an impression that they split implicits into several other more specific features.
  - agbell 5y ago
    That is my understanding of what they did. "Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent" So rather than something like implicits, that can be used N different ways, only 2 of which are practical, Scala 3 adds those 2 features explicitly.
melolife 5y ago
Implicits haven't been removed, they've just shuffled the keywords around to appease the 'implicit bad' crowd. Type classes are an incredibly important language feature, and implicit parameters are a generalization of the required functionality.
peq 5y ago
I think implicit conversions were added originally to support Java compatibility without boilerplate code. It then turned out that they could be used to simulate extension methods, which is probably the main use case for implicit classes in Scala2. And implicit parameters were probably just the result of trying to make type classes modular. The CanBuildFrom approach came later than implicit parameters (https://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist https://stackoverflow.com/questions/1722726/is-the-scala-2-8...).
oxnrtr 5y ago
CanBuildFrom got killed in 2.13, but taking a step back is exactly the right thing to do: The desire to return the same type of collection lead to overall slow performance; it turned out it's a design dead-end that Scala is still suffering from. It should simply have been abolished and replaced, instead of applying some minimal fixes in 2.13 that preserved the wrong design choices.

by sesm 5y ago

amw-zero 5y ago

I still don't fully understand it, but they wrote a lot about the topic here: https://dotty.epfl.ch/docs/reference/contextual/motivation.html https://dotty.epfl.ch/docs/reference/contextual/motivation.h...

halfmatthalfcat 5y ago

They didn't "remove" implicits in the absolute sense but they made it much more ergonomic to work with implicit-like behavior using the "given" keyword now.

sesm 5y ago
Sorry, maybe I was wrong. I was looking at this article https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html and I had an impression that they split implicits into several other more specific features.
- agbell 5y ago
  That is my understanding of what they did. "Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent" So rather than something like implicits, that can be used N different ways, only 2 of which are practical, Scala 3 adds those 2 features explicitly.

melolife 5y ago

Implicits haven't been removed, they've just shuffled the keywords around to appease the 'implicit bad' crowd. Type classes are an incredibly important language feature, and implicit parameters are a generalization of the required functionality.

peq 5y ago

I think implicit conversions were added originally to support Java compatibility without boilerplate code. It then turned out that they could be used to simulate extension methods, which is probably the main use case for implicit classes in Scala2. And implicit parameters were probably just the result of trying to make type classes modular. The CanBuildFrom approach came later than implicit parameters (https://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist https://stackoverflow.com/questions/1722726/is-the-scala-2-8...).

oxnrtr 5y ago

CanBuildFrom got killed in 2.13, but taking a step back is exactly the right thing to do: The desire to return the same type of collection lead to overall slow performance; it turned out it's a design dead-end that Scala is still suffering from. It should simply have been abolished and replaced, instead of applying some minimal fixes in 2.13 that preserved the wrong design choices.