Deprecate empty-paren (nilary) prefix unary operator

[eed3si9n]

Ref scala/bug#12055

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

This adds the following warning

deprecation.scala:4: warning: unary prefix operator definition with empty parameter list is deprecated: instead, remove () to declare as def unary_~ : Foo = this
def unary_~() : Foo = this
^
deprecation.scala:5: warning: unary prefix operator definition with empty parameter list is deprecated: instead, remove () to declare as def unary_-(implicit pos: Long) = this
def unary_-()(implicit pos: Long) = this
^

I've opted to use the term "empty-paren" as defined in https://www.artima.com/pins1ed/composition-and-inheritance.html.

Note that removing an empty parameter list from a definition does not break binary compatibility.

Under -Xsource:3, error instead.

[SethTisue]

tiny nitpick, I would suggest

"unary prefix operator definition with empty parameter list" over "empty-paren (nilary) prefix unary operator"

[sjrd]

Could you also warn when there is an empty param list followed by an implicit param list (but not if there is only the implicit param list.

For example, disallow

def unary_+()(implicit pos: Position): Tree =

but allow

def unary_+(implicit pos: Position): Tree =

This is an example taken from the Scala.js codebase where I had to make that change.

[SethTisue]

@odersky is expressing some skepticism about this over at scala/scala3#9241, see remarks there

(though in a Dotty context, it's an actual removal; here we are only deprecating, except under -Xsource:3)

[som-snytt]

PSA and reminder to self, deprecation does not entail removal, it just means "not recommended." Warning suppression means there is no motivation to break it out into a clunky lint.

Lint is just a handy way of suppressing categories of warnings, or selectively enabling them. -Wconf:cat=lint-foo:s or nowarn supersedes futzing with -Xlint:-foo,_. So similarly cat=deprecation&msg=unary.

[SethTisue]

@eed3si9n are you interested in continuing with this?

on the other ticket, Martin makes an argument about cost (that e.g. a spec update would be needed), and an argument about benefit (that the gain is small because you have immediate trouble at the use site anyway)

perhaps (not sure if this is the same as what @som-snytt is suggesting) this could simply be a lint and not a formal deprecation (where deprecation indicates intent to eventually remove). if it's just a lint, then the stakes are lower and no spec change is needed.

[som-snytt]

This is not a popular opinion, but

deprecation does not entail removal, it just means "not recommended."

As policy matter, Scala deprecations have been left in place for a decade, so pragmatically that is true.

The philosophical issue is whether deprecations (or any warnings) should be emitted by the compiler. Either something is an error or it is fine. API can be marked deprecated, not syntax. Then syntax or language features that are suboptimal must be linted.

[eed3si9n]

@SethTisue I don't understand the hangup here. Scala 2.x was happily ignoring parenthesis until 2.13.2, but Scala team (@dwijnand) decided to not lint, but instead add a warning upon auto-application to (non-Java-defined) methods in #8833. As a general direction I'm not opposed to #8833 (You know I love deprecations). The fallout of adding this deprecation in the patch release was that it started to break ppl's code with -Xfatal-warnings. This was reported as scala/bug#12055 in June.

What I'm doing here is simply to extend the line along the logical progression from Dale's warning. And as Som has pointed out deprecation simply means "hey, watch out." I'd be happy to keep it as a warning under -Xsource:3 if that's more appropriate.

"Oh no, the language spec needs to change" I think is a strawman (?), shifting goal post because I'm not suggesting we change the language specification. All I'm saying is as an implementation of Scala compiler we should let the library authors know that they are doing something that would make the compiler mad for their end users.

The right (and easy) thing to do here for 2.13 is to merge my PR :). If not, I'd ask #8833 to be demoted into a Scalafix lint together so we can get back to relaxed ().

[dwijnand]

I agree

[lrytz]

+1

[som-snytt]

Apologies for breaking the title. Probably I woke up with a hangover on Jan 4? Just guessing.

I noticed that "empty-paren" is defined in "Programming in Scala". Also that we choose not to name it in Scala 2; it is the Voldemort of signatures, possibly because his nose is like ().

https://users.scala-lang.org/t/what-does-it-mean-parameterless/9580/3?u=som-snytt