Now that public is the default visibility modifier, is the public keyword obsolete, and can it be removed? (Scala doesn’t have one, for this very reason.)
I also noticed that stdlib still uses public all over the place, which doesn’t serve as a good example.
The public keyword can be used to increase the visibility of a protected method you inherit from the superclass, so no, it’s not entirely obsolete.
As for the standard library source code, it may or may not remain there in 1.0 - this is something that we’ll need to discuss inside the team.
Good to know. If this is the only meaningful use of public these days, it could be eliminated by requiring the overriding function to be explicit about its visibility, rather than inheriting it. (This is also how Scala avoids the need for a public modifier.) This seems in line with Kotlin’s “WYSIWYG” attitude towards visibility (visibility modifier defaults to public regardless of context), and gets rid of a whole keyword that has already become redundant for the most part.
I support explicitly specifying visibility instead of inheriting it.
In my opinion, this behavior would be surprising in a bad way. Right now, if you override a protected method and don’t specify any visibility, it stays protected. If we changed the rules to what you suggest, it would silently become public, without the user realising it. That’s not WYSIWYG, because the “public” modifier is not there to be seen.
I can see some value in this, but does it justify a whole keyword? Also, public should not be allowed in places where it has become entirely redundant (i.e., all other places).
For comparison, Scala, Java, and C# don’t inherit visibility modifiers (but only Scala has public visibility as default like Kotlin). C# emits a compile error if the overriding method is not given the same visibility modifier as the overridden method.