SIP public review: Open classes

It feels to me that this is a departure from Scala as I know it. Until now, by default, things are public and open, and you have to think about restricting your API. Now you have to think about opening as well.

The fact that the default class C easily leads to warnings seems quite annoying, and gives people the feeling that they’re doing something wrong. In the REPL a special case would be needed, otherwise writing class C and then class D extends C on the next line would warn.

One aspect that bothers me is that the proposal changes the semantics of existing code. When upgrading, a library author needs to go through all the code and make sure he doesn’t miss marking the right (or all non-abstract/sealed/final) classes open, otherwise clients break.

The feature is also problematic for cross-building with 2.13 – should it be disabled in Scala2-mode?

Since we are in the context of restricting subclassing: was it considered to make sealed transitive (propsed by @lihaoyi on the old thread)?

7 Likes