Open Blaisorblade opened 6 years ago
BTW, I suspect a related issue came up in https://github.com/lampepfl/dotty/pull/4133#pullrequestreview-105511057, though I might be confused — this one doesn't crash Dotty, just produce questionable results.
We already disallow public classes extending private classes in some situations:
object A {
private trait Foo
class Bar extends Foo
}
-- Error: try/i4228b.scala:3:8 -------------------------------------------------
3 | class Bar extends Foo
| ^
| non-private class Bar refers to private trait Foo
| in its type signature Object with A.Foo{...}
We could extend this to private-qualified superclasses and to classes defined directly in packages.
It might be possible to use https://github.com/olafurpg/scala-experiments to check how frequently projects have public classes extending private classes and if there are actual usecases for this.
Here was one use of extending private classes — the goal was to reuse implementation: https://github.com/scala/scala/commit/51ec62a8c3
Your comment in #4133 shows another (smaller) instance.
In both cases, widening inferred types to accessible ones seems a possible alternative in principle, though I'm not sure how hard it is to do in practice. I think this is yet-another-instance of a well-known problem with ML modules, the "avoidance problem" (@odersky mentioned it days ago), but I am not too familiar with solutions.
Type inference sometimes produces inaccessible types, but should widen then to visible ones. An example from 2012: https://groups.google.com/d/msg/scala-internals/0j8laVNTQsI/B6fu1e4KJ2sJ
Running the REPL with the output confirms the issue is still there:
(BTW, the other example in that email is instead fixed, arguably better in Dotty than in Scalac):