Audit which private/fork (`-Y*`) options should be lifted to one of the stable categories

[Gedochao]

Compiler version

nightly

Context

A number of -Y* options are considered private (unstable), while in reality they're widely used and could be considered production-ready.
We need to look at them case-by-case, potentially lift them to their appropriate categories and deprecate their -Y* aliases, where applicable.
Consider this an umbrella ticket to tidy this up.

[SethTisue]

Perhaps there are -Y options that really ought to only exist in nightly/experimental compilers? A tradition of using -Y for experimental stuff developed over the many years before the "experimental" concept arose and was codified, but we could reconsider that tradition now.

[Gedochao]

Perhaps there are -Y options that really ought to only exist in nightly/experimental compilers?

I'm not suggesting to get rid of -Y* options completely.

For example, options related to capture checking (like -Ycc-debug or -Ycc-no-abbrev) can probably stay the way they are. We do, however, have a bunch of older options which stayed in this category for a long while and their status could perhaps be reconsidered.

[odersky]

Most -Y options are debug options to get more insight into what the compiler does or they are options relating to experimental features. Another bunch is options that tweak the compiler output, but that need expert knowledge to understand what they do. I think these can stay. But the following could be reclassified as -X options since they have been used for a while and are compiler-independent.

  val YnoImports: Setting[Boolean] = BooleanSetting("-Yno-imports", "Compile without importing scala.*, java.lang.*, or Predef.")
  val Yimports: Setting[List[String]] = MultiStringSetting("-Yimports", helpArg="", "Custom root imports. If set, none of scala.*, java.lang.*, or Predef.* will be imported unless explicitly included.")
  val YnoGenericSig: Setting[Boolean] = BooleanSetting("-Yno-generic-signatures", "Suppress generation of generic signatures for Java.")
  val YnoPredef: Setting[Boolean] = BooleanSetting("-Yno-predef", "Compile without importing Predef.")

And the following are about features that are in train of stabilization. They need a decision when they are stable in which case they could be promoted to -X options or become default behavior.

  val YexplicitNulls: Setting[Boolean] = BooleanSetting("-Yexplicit-nulls", "Make reference types non-nullable. Nullable types can be expressed with unions: e.g. String|Null.")
  val YcheckInit: Setting[Boolean] = BooleanSetting("-Ysafe-init", "Ensure safe initialization of objects.")
  val YcheckInitGlobal: Setting[Boolean] = BooleanSetting("-Ysafe-init-global", "Check safe initialization of global objects.")

[odersky]

There are also options related to old Scala versions like -Ykind-projector. These will go away eventually. Since everybody is now used to their -Y status I don't think it's useful to upgrade them to -X before deleting them in some future version.

[odersky]

Actually, let's hold off on the imports settings.

 val YnoImports: Setting[Boolean] = BooleanSetting("-Yno-imports", "Compile without importing scala.*, java.lang.*, or Predef.")
  val Yimports: Setting[List[String]] = MultiStringSetting("-Yimports", helpArg="", "Custom root imports. If set, none of scala.*, java.lang.*, or Predef.* will be imported unless explicitly included.")
  val YnoPredef: Setting[Boolean] = BooleanSetting("-Yno-predef", "Compile without importing Predef.")

We need to have a (SIP) discussion about that. In my view it is a code smell to fiddle with imports via a compiler option and not in source. So -Yimports should definitely seen as experimental (and undesirable, maybe we should even remove it?). For replacing -YnoImports and -YnoPredef we need better ways to do that in source. Right now we can do it for -YnoPredef like this:

import Predef.{String as _}

object Test:
  summon[Int] // error: not found: summon

But that's very roundabout: (1) We need to know that the repeated import actually replaces the default one. (2) We need to import something and then rename it to nothing.

It would be great if this worked for at least all root imports with a better syntax. My preferred syntax would be:

 import Predef.{}
 import scala.{}
 import java.lang.{}

Or, as the note in Importinfo.scala suggests, allow the "import override" for all imports and demand an explicit "override". I.e.

 override import Predef.{}
 override import scala.{}
 override import java.lang.{}

In any case. I would not elevate -Y import options to officia;l status before this question is settled.

[odersky]

Here's the note:

  /** The root import symbol hidden by this symbol, or NoSymbol if no such symbol is hidden.
   *  Note: this computation needs to work even for un-initialized import infos, and
   *  is not allowed to force initialization.
   *
   *  TODO: Once we have fully bootstrapped, I would prefer if we expressed
   *  unimport with an `override` modifier, and generalized it to all imports.
   *  I believe this would be more transparent than the current set of conditions. E.g.
   *
   *      override import Predef.{any2stringAdd => _, StringAdd => _, _} // disables String +
   *      override import java.lang.{}                                   // disables all imports
   */
  def unimported(using Context): Symbol =

[odersky]

Maybe there are other options like -YnoGenericSig that suppress some output in the generated files. Maybe these could be moved to -X since the goal is presumably to cut down on generated file size, which easy to understand.

[SethTisue]

Perhaps there are -Y options that really ought to only exist in nightly/experimental compilers?

Let me expand on this a bit.

In the chat rooms, I've lost count of how many puzzled people we've had to inform that -Y is supposed to be a signal that a feature is experimental and/or internal. We ourselves know this, but normal Scala programmers cannot be expected to know it — especially newcomers. -X, -Y, it's just alphabet soup to them.

It's especially common that people try -Yexplicit-nulls, have problems all over the place even on simple examples, and are confused and/or disappointed.

I've just opened scala/docs.scala-lang#2976 about improving the Scala 3 reference documentation to try and head off this problem, but I'm also interested in discussing possible changes like making known-dubious features like -Yexplicit-nulls less accessible.

[lrytz]

About -Yimports, this feature can be very valuable for managing migrations / cross-building in large codebases.

It seems the most pressing issue is -Y-enabled language features that should instead be handled the same as other experimental language features. Since 3.4.0 has the -experimental flag, all experimental features are available on release compilers anyway, so there is probably no reason to use a -Y flag instead.

[odersky]

We have to strike a balance but putting things under more locks is not the right way to proceed. -Yexplicit-nulls is a good example. If it was so well hidden that nobody could use it, explicit nulls will never see the light of day. That turns Scala 3 into a Scala 2 where things never change and the language becomes stagnant.

If we were a big organization we could develop a new feature behind walls, test it thoroughly and release it when it is fully cooked. But we are not. We rely on volunteer work without fixed schedules. So we can discuss about names. I personally think that all -Y should off-limits for non-expert users who don't know what they are doing. Then we don't need to invent yet another name and confuse people.

And, -Yimports should stay a -Y option because it is really bad and would be a huge problem if used widely. If an expert user needs it for cross-building a large library, fine. -Y options are for that. But we should never promote this as good programming practice.

[lrytz]

-Yimports should stay a -Y

Sure, I was just pointing out that there's a valid use case. To me it's fine if -Y is a grab bag of debugging options and some advanced tools.

For experimental language features I think it's worthwhile having one mechanism.