Qualified private is not simply private

[som-snytt]

Minimized code

➜  snips ~/scala3-3.0.0-M1/bin/scala
Starting scala3 REPL...
scala> class C { private[C] def f = 42 }
// defined class C

scala> class D extends C { override def f = 17 }
// defined class D

scala> D().f
val res0: Int = 17

scala>

Output in Scala 2

Welcome to Scala 2.13.3 (OpenJDK 64-Bit Server VM, Java 11.0.7).
Type in expressions for evaluation. Or try :help.

scala> class C { private[C] def f = 42 }
class C

scala> class D extends C { override def f = 17 }
                                        ^
       error: method f overrides nothing

scala>

Expectation

Although qualified private is dicey, we expect qualified private to immediately enclosing class to be exactly the same as private to immediately enclosing class, private tout court.

This is extracted from scala/bug#2568.

An alternative coping mechanism might be a warning and Scalafix for "redundant qualified private".

This gibes with removing private[this]; possibly private[C] where C is the immediately enclosing class should be disallowed.

[odersky]

Although qualified private is dicey, we expect qualified private to immediately enclosing class to be exactly the same as private to immediately enclosing class, private tout court.

I contest that. They are not the same. You can only make them the same by making qualified private to the immediately enclosing class fundamentally different from qualified private to an outer class. And that's clearly undesirable.

In fact, qualified private to the immediately enclosing class is pretty useless. We could forbid it. But then, why spend the effort of detecting that case if nobody sane would actually write it, and it's just another annoying rule we have to add to the spec?

[som-snytt]

They are not the same.

I don't understand why; I thought it was just syntax; later, I will spend some time with the spec and googling old threads.

fundamentally different ... And that's clearly undesirable.

I'm missing something obvious, so I'll spend more time with qualified private. This is like that math textbook expression, "It is obvious that...", which, when it is not obvious, suggests you re-read the previous material.

We could forbid it.

The use case would be that you start with an inner class and refactor so that the private[C] is redundant.

As a lint, it need not be in the spec, but just a "style" check. (Note to self.)

nobody sane would actually write it

OK, I'll cop to that.

[sjrd]

True private is guaranteed not to be overridable, under any circumstances. Not even in places that can see the method, such as an inner class that would extend its outer class or a class in the companion object. Qualified private does not have that guarantee, therefore they are not automatically considered final (that has an impact on tailrec, for example).

[som-snytt]

The spec language for inheritance changed in scala/scala#4512