do you want the Scala Platform to use scala.*, not something like scalax.*?

My understanding is that the scala namespace is owned by EPFL and platform modules will not be re-rooted. I think it would be a poor idea to do so. Users need to understand what’s part of the core language and what isn’t.

My understanding is that the scala namespace is owned by EPFL and platform modules will not be re-rooted.

We haven’t discussed yet, but there exists the possibility that they will be re-rooted under something similar to scala.platform. I’ll bring this up in our next meeting. My personal opinion is that that users of the Scala Platform have a clear idea of what’s part of the language and what isn’t – they have to add/choose a Platform in their build (not like the standard library that in any Scala installation is accessible).

Sorry for the unclear wording. To clarify: I expect the Scala platform might be adopted more than some of the libraries that join it — I’d guess more people are going to know about the platform than about better-files. And (IIRC like others) I expect that to matter more for beginners.

You might be right about the UX, but “more adopted” is still an expected consequence of stated goals; the UX should be designed to this end. IIUC, a goal is to get some advantages of a more “batteries included” standard library, without requiring LAMP to maintain it (which doesn’t work). If we quote https://scalacenter.github.io/platform-staging/platform.html we get something vaguely similar:

The Scala Platform is a stable collection of libraries with widespread use and a low barrier to entry for beginners and intermediate users.
Through a collaborative and meritocratic development process, the Scala Platform provides a smooth and productive programming experience right from the start, both for learning purposes and production use.

But catering to beginners might suggest a better UX than discussed till now… EDIT: forked off a thread on this direction.

there exists the possibility that they will be re-rooted under something similar to scala.platform

I feel strongly that going forward, only the core standard library should stay in the scala._ namespace (or any of its sub-namespaces).

It’s unfortunate that modules like scala-parser-combinators are already in that namespace, but I think that is a historical accident, stemming from the standard library’s bad old kitchen-sink days, and doesn’t qualify as a precedent for our current choices. (We should be looking to move those modules out of scala._ space, even.)

tpolecat has already covered most of the main reasons for my opinion. I second his points.

Also, it hasn’t been explicitly been pointed out, perhaps because it’s something we all already know, but scala._ is imported by default into every Scala program. This is a major reason it is so privileged and a major reason we should be very conservative about introducing anything into it.

By contrast, in Java, only java.lang.* is automatically imported, not all of java.*. Things are different in Scala because we have nested packages and Java doesn’t, but that difference means we need to be more conservative than Java about namespace real estate, not more liberal.

It introduces a purely cosmetic breaking change to every library, all of which have “widespread adoption” already by definition.

I have also step forward and say that I agree with this statement. At least, it shouldn’t be required to reroot libraries.

About the scala._ namespace, I tend to agree with @SethTisue. But I guess what @jvican is striving for is some sort of namespace for the Scala Platform that platform libraries could move to if it would somehow be beneficial to them.

So I guess the question is, if putting stuff in submodules of the scala namespace is out, what namespace could the Scala Platform have, for the module authors that want to be part of some kind of Scala Platform namespace?

So I guess the question is, if putting stuff in submodules of the scala namespace is out, what namespace could the Scala Platform have, for the module authors that want to be part of some kind of Scala Platform namespace?

platform._ ?
or even the more verbose platform.core._
or the more explicit scalaplatform._

Why? Because we all agree that there can (and should) be alternative platforms. But there is no reason that one library cannot be part of two, or more, platforms! In that case, if each platform has its own platform package, that library cannot exist. Conclusion: it doesn’t make any sense.

That would get really awkward when a library was introduced into a ScalaCenter platform, changed its package to platform.scalacenter._ and was then also included into the lightbend platform (or any other combination)

I don’t see a clear advantage for library authors in exploiting a standard platform package naming.
After considering the criticism moved against the introduction of such package and the fact that no one is trying to actively defend such proposal, I would consider this topic closed.

I thought of a consideration that hasn’t been mentioned. If you’re in scala namespace, you have access to things which are declared private[scala]. Allowing this violates modularity. When we’re maintaining the standard library, we would like to be free to refactor things declared private[scala] without worrying whether we’re breaking things that are somewhere else, in another repository entirely, maintained by different maintainers.