-
Notifications
You must be signed in to change notification settings - Fork 21
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
Deprecate nilary unary prefix operator #12055
Comments
One example for the record: scala-js/scala-js@0f7c97a |
I'll do it - scala/scala#9085 |
For what it's worth this behavior is the same on Dotty 0.25.0-RC2 too: scala> class Foo {
| def unary_~() : Foo = this
| }
| val f = new Foo
| val f2 = ~f
5 |val f2 = ~f
| ^^
| method unary_~ must be called with () argument |
I'll open an issue there as well. |
Not sure why a lint isn't sufficient. The purpose of lints is to alert about features that are legal but have sharp edges. The direct analogy here would be multiarg infix application: deprecating the application syntax does not entail deprecating the definition of an operator that takes multiple parameters. It could still be invoked Similarly, |
Based also on the discussion on the Dotty ticket, I think I now agree. (Initially, I hadn't even considered having it be a lint instead.) |
This is a pitfall Scala 2.13 dug by deprecating auto-application of empty-paren (nilary) methods in a patch release 2.13.3 (scala/scala#8833), so I think
I tried - scala/scala#7792 |
To expand, I retracted my question about using lint instead on the PR scala/scala#9085 (comment) Especially for this feature intersection, which was never a good idea; it doesn't even count as a style choice. And in any case, it is probably rarely exploited, so It says my previous comment was only a few weeks ago, but it feels like many months. With my little joke about |
reproduction steps
using Scala 2.13.3-bin-d23424c
problem
Now that auto-application is deprecated, a prefix with a nilary creates a warning that cannot be avoided while maintaining a prefix position (or permanently applying warning suppression). To resolve this, we need to deprecate this possibility from the definition site.
The text was updated successfully, but these errors were encountered: