One important note would be that just using a single type parameter is actually not enough for guarantee same type. For example if you pass a `List[String]` and a `List[Int]` the compiler will simply infer `Any` for `A` and thanks to Covariance and Liskov both lists would be applicable and of the same type. Using `=:=` fix this issue since we test for equality after inference.
Yes, but not built-in. There is a way to exploit implicit ambiguity to make the code not compile: not because there isn't an implicit that satisfies the evidence, but because there are too many.
@@rockthejvm Is there any true "for complete beginners to programming" book or course in the Scala world? or is there any planned? I think many people(like me) would like to learn Scala truly from the start, and not depend on Python or Javascript courses for complete beginners to learn the fundamentals with one language just to waste time learning the particularities of that language and then need to learn from scratch Scala.
Thanks for the video, that's an interesting trick. But at the end you still had to modify the method's signature in every described solution. So as I understand, there is no way to do it without modifying or wrapping the original method? I expected that the final trick will be something like importing/declaring an implicit into the context, which changes the behaviour of the original method.
In all cases we "wrapped" the original method. If you can change the method signature, you should add that extra argument list to enforce the type relationship.
You can keep the original signature if you "hide" the implicit block with a macro in Scala 2 (inferImplicitValue) or inline method in Scala 3 (summonInline, summonFrom)
![Scala & Kotlin Comparison, What Kotlin Can (Graciously) Steal from Scala [KKON 2024 talk]](http://i.ytimg.com/vi/UNSIY-Jo8k8/mqdefault.jpg)
One important note would be that just using a single type parameter is actually not enough for guarantee same type.
For example if you pass a `List[String]` and a `List[Int]` the compiler will simply infer `Any` for `A` and thanks to Covariance and Liskov both lists would be applicable and of the same type.
Using `=:=` fix this issue since we test for equality after inference.
Great content! This channel deserves way more attention. Keep up the good work!
Thanks!
interesting... is there an equivalent to NotGiven in Scala2 ?
Yes, but not built-in. There is a way to exploit implicit ambiguity to make the code not compile: not because there isn't an implicit that satisfies the evidence, but because there are too many.
@@rockthejvm can you give more details or make a video about it? :)
I miss the pre-Scala 3 days when you could use IDEA without needing to frequently manually trigger a compile. :(
Freaky. I can't imagine that I will ever use that..... but cool!!
Any plans to convert all your courses for Scala 3 ?
Recording as we speak!
@@rockthejvm Is there any true "for complete beginners to programming" book or course in the Scala world? or is there any planned? I think many people(like me) would like to learn Scala truly from the start, and not depend on Python or Javascript courses for complete beginners to learn the fundamentals with one language just to waste time learning the particularities of that language and then need to learn from scratch Scala.
FWIW, this is in the dotty reference page on givens (dotty.epfl.ch/docs/reference/contextual/givens.html), under the Negated Givens section.
Thanks for the video, that's an interesting trick. But at the end you still had to modify the method's signature in every described solution. So as I understand, there is no way to do it without modifying or wrapping the original method? I expected that the final trick will be something like importing/declaring an implicit into the context, which changes the behaviour of the original method.
In all cases we "wrapped" the original method. If you can change the method signature, you should add that extra argument list to enforce the type relationship.
You can keep the original signature if you "hide" the implicit block with a macro in Scala 2 (inferImplicitValue) or inline method in Scala 3 (summonInline, summonFrom)
There's no need to import or define new instances of NotGiven
Thank you for this video :D
Super cool!