3 ms·

Apart from it's not all accurate. Implicits have been part of Scala from the start and are used heavily throughout all the core libraries and many large project

• bad_user 14y ago
  Implicit conversions are used heavily, they aren't going anywhere, but their usage is taking a back seat to other means for achieving the same thing, like context bounds, which is a cheap(er) and safer mechanism for type-classes (jargon doesn't help in learning sadly, type-classes are like open interfaces, such that you can make any existing type implement it - think about adding Ordering to an existing type, like integers and then using it in a sort() that then works on all types with Ordering implemented). Also implicit classes are only a subset of implicit conversions. Implicit classes are like "extensions methods" from C# (only a little more potent, in the true Scala fashion :)). Their usage is simpler, reasoning about them is simpler, if the implicit class inherits from AnyVal, then performance is better since the compiler will not create wrapper objects, and so on. It's a subset because implicit conversions allows for viewing any type A as any other type B. This is powerful, but also has gotchas that people fall into ... for one, these conversions are not transitive. So if type A can be viewed as type B and type B can be viewed as type C, that doesn't make type A viewable as type C. To make this work you have to deploy really complicated logic to help the compiler do what you mean and it turns out that in most cases that's not what you really wanted to do anyway. It's also unclear how adding transitivity will interact with other features or what gotchas that may have, while making the compiler slower and more complicated, but put plainly - this is not the kind of feature that does the right thing. I said "experimental", because the feature itself is a feature where the bounds of what you can and cannot do aren't at all clear and require extensive knowledge of the compiler's decision process, which means it's ripe for replacement as soon as something better comes along, equally powerful, but without the gotchas. This hasn't happened yet, but it probably will, though as a disclaimer I'm also a beginner so I have no way of knowing that. Either way, I'm happy that Scala is not a frozen language and the team working on it is trying to find ways to safely evolve it. It's pretty bad having to live with broken features for legacy reasons. I also said "implicit conversions", not implicit parameters. All languages have implicit parameters, even if we are talking about the Singleton pattern / global state or dependency injection. Scala's mechanism for implicit parameters is better, because it's light, lexically scoped, overridable and compile-type checked, having the side-effect that it scares beginners away since those implicits end up in function definitions ... but I think that's better than carrying around implicits of which you don't know about and anything that helps with referential transparency is Good.