So I am going to state here what I stated on the initial proposal PR, which is that I am not a fan of the proposal in general because I think its solving the wrong problems. In summary my points are
- The real issue with implicits is not how they are defined or used, but the fact that the compiler gives completely terrible diagnostics especially with chained implicit resolutions. This is not going to solve this. Its also unclear how
impliedis going to work when combined with other keywords.
- The only real problematic part of implicits is implicit conversions, which people have (rightly) complained about and are already deprecated and considered an anti-pattern
- The current
implicitis actually much more familiar with the current mechanics of Scala compared to this proposal.
implicitworks the same way as keywords like
final, i.e. they modify a definition to state that “this variable can be implicitly provided”. Likewise using it in a parameter list states that “I want to get a variable from a type that has been implicitly defined”. These concepts are not hard to understand.
- This proposal goes against the nature of Scala where we do have control over how variables are defined. There is a difference between an
implicit lazy valvs
implicit def(just like there is a difference between
final val), i.e.
implicit lazycan combined with
traitcan be used for compile time DI
implicit defan be used for constructing DSL’s in a safe and principled manner.
I would rather the effort be spent improving the current implicits because honestly we are already 80% there. This includes
- Giving sane compiler errors about missing implicits (i.e. https://github.com/tek/splain should be part of the scala compiler, not a plugin)
- Fixing discrepancies when it comes to implicit function application. I.e. If you have function like
This is going to behave differently on
def doSomething(key: String)(implicit ctx: Context): Map[String, String]
In the former the
def doSomething(key: String): Map[String, String]
.applyis going to be providing the
Contextwhere as in the latter the
.applyis going to point to the
key. In both cases
applyshould point to
keyand if you want to explicitly provide the implicit context it should be something like
This (along with some other changes) would fix all of the currying issues that we have with implicits.
There are probably some other things which I have missed but the tl;dr is that we should fix the current implicits rather than making an entirely new proposal which isn’t even in the spirit of the language.
IDE’s also need to provide better inspections, Intellij as of late is doing an excellent job here (it will actually show you implicit chains and it now has the ability to tell you where implicits are being used which is incredibly handy). When metals does the same a lot of the quality of life issues with implicits should be solved.