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
implied
is 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
implicit
is actually much more familiar with the current mechanics of Scala compared to this proposal.implicit
works the same way as keywords likefinal
, 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 val
vsimplicit lazy val
vsimplicit def
(just like there is a difference betweenfinal def
vsfinal val
), i.e.-
implicit lazy
can combined withtrait
can be used for compile time DI -
implicit def
an 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 ondef doSomething(key: String)(implicit ctx: Context): Map[String, String]
.apply
rather than
In the former thedef doSomething(key: String): Map[String, String]
.apply
is going to be providing theContext
where as in the latter the.apply
is going to point to thekey
. In both casesapply
should point tokey
and 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.doSomething("myKey").explicitly(someContext)
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.