I’ll continue the theme here with some feedback about deprecation of Implicit Conversions in my pet flavor.
In the pre-sip thread, it is suggested that implicit conversions for bulk extension can be replaced with a construct like this:
Unfortunately, I believe that will break a lot of code. Extensions as they currently exist break right-associativity*. So, every line of code that uses
++: (just to mention the ones on
ArrayOps) will be broken and need to have its operands flipped to compile again**.
(* For some definitions of “broken” and “by design”)
(** This one is true regardless of what you think about the intentionality of extensions behavior with right-associativity)
Of course, you could perhaps come up with a means to exclude the right-associative operators from the export above and then add extensions to the
Array object like so:
extension [A] (a: A) def +: (arr: Array[A]) = ... extension [A] (it: IterableOnce[A]) def ++:(arr: Array[A]) = ... extension [A] (arr: Array[A]) def ++:(arr: Array[A]) = ...
But then we’re right back to this issue:
Not to mention that you will then have to do the same for every type that currently benefits from implicit conversion to every other collection type in the standard library. And that’s not to mention code outside of the standard library making use of implicit conversion to types with right-associative operators on them.
It seems to me that we either need a very long lead time to wean the entire ecosystem off of right-associativity in every use case, or we will still need some mechanism for adding them to (er… extending(?)) types as they currently behave.
Having said all of this, I’m not particularly a fan of implicit classes / conversions. But given the behavior of extensions around this topic, I don’t currently see another option that can achieve the same goals in this regard.