-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Unintended recursive implicit conversion #13542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
duplicates #10947 Extensions are not immune, but it depends on whether they come from implicit scope:
The 2-step similar to Scala 2 is at the bottom of https://docs.scala-lang.org/scala3/reference/contextual/extension-methods.html where it explains: "This second rewriting is attempted at the time where the compiler also tries an implicit conversion..." This is a classic puzzler; I hit it every time I code a quick example because converting string to int is the first thing I reach for, like reaching for my eyeglasses from the nightstand when my sleep is disturbed, and always knocking over the water glass that is also handy. |
Maybe we could remove the method providing the implicit conversion from the implicit scope just inside this method? I guess that should be relatively easy and not influence any other rules of resolving implicits. |
Broadens Martin's fix for scala#13542 Fixes scala#9880 Also, exempt Boolean's && and || methods, which aren't set up as having by-name parameters. Co-authored-by: Dale Wijnand <[email protected]>
Compiler version
3.0.2
Minimized code
Output (at runtime)
Less minimal but more self-contained code
Output (at runtime)
Expectation
The first snippet was a real puzzler to me and I spent quite a lot of time trying to figure out what was happening there until I found the reason shown in the second snippet (in the first one it's about
toInt
being defined onInt
and at the same time added toString
fromStringOps
byaugmentString
fromPredef
).Not sure whether this would be easy to achieve with the current scheme of resolving implicits but it would be good to avoid the cyclic call of
barToFoo
by choosing the method added by the old style extension. Note that there's no cycle if we use a new style extension method instead.The text was updated successfully, but these errors were encountered: