Deprecate nilary unary prefix operator

[soronpo]

reproduction steps

using Scala 2.13.3-bin-d23424c

class Foo {
  def unary_~() : Foo = this
}
val f = new Foo
val f2 = ~f //deprecation warning for auto-application

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.

[sjrd]

One example for the record: scala-js/scala-js@0f7c97a

[eed3si9n]

I'll do it - scala/scala#9085

[eed3si9n]

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

[soronpo]

I'll open an issue there as well.

[som-snytt]

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 xs.+=(1,2).

Similarly, f.unary_~(). That is not funnier than p.lines_!().

[SethTisue]

Not sure why a lint isn't sufficient

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.)

[eed3si9n]

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 ⚠️ in this case deserves the same degree of visibility.

deprecating the application syntax does not entail deprecating the definition of an operator that takes multiple parameters.

I tried - scala/scala#7792

[som-snytt]

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 -Wconf mechanism is even more appealing.

It says my previous comment was only a few weeks ago, but it feels like many months. With my little joke about f.unary, I was thinking f.unerary. But it's worth adding that Dotty leading infix warning includes unary_!, so maybe that is a reason to see trailing-operator names simply as operators.