Grandfather clause for non-nullary overrides nullary

[Som Snytt]

This seems like an easy one.  Should it complain about the override in Z?

It seems to be OK with it, if the grandfather has a param list.

The context was toString methods with extraneous parens.  The spec (and Definitions) appears to define Any.toString without parens, so it would be nice if -Xlint warned in this case.  I don't know what the internal representation looks like, when RefChecks checks refs.

But I noticed that this problem serves as a workaround for SI-6978 (in lieu of reporter filtering), where class J was a Java class and the warning at S was undesirable.

Also, -Ylog:refchecks does show it comparing Z.f to both Y.f and X.f.

$ scala -Xlint
Welcome to Scala version 2.11.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_05).
Type in expressions to have them evaluated.
Type :help for more information.

scala> class A { def f = "a" } ; class B extends A { override def f() = "b" }
<console>:7: warning: non-nullary method overrides nullary method
       class A { def f = "a" } ; class B extends A { override def f() = "b" }
                                                                  ^
defined class A
defined class B

scala> class X { def f() = "x" }
defined class X

scala> class Y extends X { override def f = "y" }
defined class Y

scala> class Z extends Y { override def f() = "z" }
defined class Z

scala> trait T { def foo: Int }
defined trait T

scala> class J { def foo() = 0 }
defined class J

scala> class S extends J with T
<console>:7: warning: non-nullary method overrides nullary method
       class J { def foo() = 0 }
                     ^
defined class S

scala> trait U { def foo(): Int }
defined trait U

scala> trait T extends U { def foo: Int }
defined trait T

scala> class S extends J with T
defined class S

[Lukas Rytz]

I think it should warn always when there's no Java classes involved.

If one of the involved methods comes from Java, it should probably never warn.

In your example though, I think it should warn on Z even if X is from Java.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Som Snytt]

I don't think I was aware of the special rule.

http://www.scala-lang.org/files/archive/spec/2.11/05-classes-and-objects.html#overriding

A special rule concerns parameterless methods. ... f is also assumed to have an empty parameter list.

Or at least it slipped from consciousness. Maybe I don't override enough to make it stick.

So toString has parens (please don't say duh)

scala> class X { override def toString = "x" }
defined class X

scala> new X().toString()
res2: String = x

and the other recent example was isWhole, where the same argument applies as for toString: if someone gave it parens in a superclass, you can leave them off for style in your subclass and call sites.

In fact, I think this might be a spare the parens day.

scala> :pa
// Entering paste mode (ctrl-D to finish)

class Y extends math.ScalaNumericConversions {
  def doubleValue(): Double = ???
  def floatValue(): Float = ???
  def intValue(): Int = ???
  def longValue(): Long = ???

  // Members declared in scala.math.ScalaNumericConversions
  def underlying(): Object = ???
  def isWhole = false
}

// Exiting paste mode, now interpreting.

defined class Y

scala> new Y().isWhole()
res3: Boolean = false

and not

Boolean does not take parameters

[Lukas Rytz]

I was not aware of that either - the rule is probably necessary to avoid too many

surprises. But being consistent in the source code is better anyway. So it makes

sense to lint-warn about it.