-Xsource:... should be documented as not for use in production/publishing

[SethTisue]

I have seen it come up many many times on Gitter and elsewhere, that people thought -Xfuture (which doesn't exist anymore) or -Xsource:... was something it was just fine to sprinkle on their scalacOptions without thinking too much about it

for example, -Xfuture is included in https://tpolecat.github.io/2017/04/25/scalac-flags.html , which is widely referred to (/cc @tpolecat)

over at https://docs.scala-lang.org/overviews/compiler-options/index.html the entry for -Xsource just says:

Treat compiler input as Scala source for the specified version, see #8126

I suggest that -Xsource:... be documented as something that should only be used for experimenting and to get migration information, you shouldn't enable it when building something you're going to deploy or publish

why? because these flags enable poorly-tested combinations of possibly half-baked stuff, the version of the compiler you get when you enable this hasn't been QA'ed anywhere near as heavily as the default one has

and since we have published the reference to #8126, I would also suggest that the description on that ticket be improved so that anyone consulting it will see the same warning text

[eed3si9n]

I actually think more people would be happier if they used -Xlint, -deprecation, and -Xfatal-warnings (on whatever the main Scala version you work with the most), similar to what Rob suggests, and I'd include -Xsource:2.14.

If testedness of -Xsource:2.14 is somehow the problem (do you have specific behavior in mind like #11657 and #11644?), then we should fix that instead.

[SethTisue]

I don't have specific behavior in mind. It's just we don't run the Scala test suite with -Xsource:2.14 enabled, and we don't run the community build that way either, and (re "we should fix that"), doing that seems like an impractical expansion in scope to me.

[eed3si9n]

To expand on my "then we should fix that instead" position, I think we should be fairly conservative on what we include into -Xsource:2.14. For example, in scala/scala#6325 I deprecated the procedure syntax and dropped it completely in -Xsource:2.14. If you can bring your code base up to that, there's no reason not to recommend that behavior for use in production/publishing. This is an example that also highlights the integration testing to be difficult because it would require large-but-clean code base with zero procedure syntax.

[som-snytt]

A heavy hand in the linked PR.

[SethTisue]

Just a note that over the course of the last 3.5 years, things have changed and -Xsource:3 has gone on to acquire a rather more, shall we say, "mainstream" status than it had in 2019.

[som-snytt]

It would be nice to get the project on -Xsource:3, early defs being the hang-up. The implicit search change that is now -Yscala3-implicit-resolution is the biggest "fail" in making it a no-brainer otherwise, just because predictability is paramount. The other factor is that the source option cannot be taken piecemeal, but all or nothing.

It's so much nicer to write import mutable.*. There's a short list of "things that make -Xsource:3 worth it." "Leading infix" is another, but probably under-exercised for bugs, especially since it fell behind dotty changes.

[SethTisue]

It would be nice to get the project on -Xsource:3,

Oh, actually bootstrap using it? That's an idea that hadn't occurred to me before...