Same as Scala 2 bug https://github.com/scala/bug/issues/12055
class Foo {
def unary_~() : Foo = this
// also bad
def unary_+()(implicit pos: Long): Foo = this
}
val f = new Foo
val f2 = ~f //method unary_~ must be called with () argument
https://scastie.scala-lang.org/NKZQM3d8RrGYRYFoewJyQw
Auto-application is disallowed and there a prefix def with a nilary(empty parenthesis) creates an error that cannot be avoided while maintaining a prefix position. To resolve this, we need to deprecate this possibility from the definition site.
It's not quite clear how this should be done. Do you want to disallow all parameters on methods named unary_n? what exactly is the pattern? I fear we will need quite a bit of spec language to cover this.
Also, is it really worth it? With a single unit test for your operator you'll find out that this will not work.
This is the same as #6192 which we closed without solving it.
There was a PR submitted to Scala 2 to resolve this issue:
https://github.com/scala/scala/pull/9085
It's not quite clear how this should be done. Do you want to disallow all parameters on methods named unary_n? what exactly is the pattern? I fear we will need quite a bit of spec language to cover this.
The PR in Scala 2 is sufficient enough. It removes a single empty-parent option from unary_x defs. We could go further and disallow all non-given parameter blocks from unary_x defs (given block support is required).
I note that #9085 comes without a spec, which makes it incomplete. I would be interested to see what a spec would look like. I suspect it would look rather out of place.
A spec would be very similar to number 3. in https://dotty.epfl.ch/docs/reference/changed-features/operators.html#details-1. Something like:
The first parameter list of a unary operator method must not be empty. As a reminder from Section Prefix Operations, a unary operator is one whose name is "unary_op" for op in
+ - ! ~.
I think somebody else should take this on.