Promote `-Ytasty-reader` to `-Xtasty-reader`?

[SethTisue]

we initially added it as -Y because it was new, but the TASTy Reader is here to stay and there aren't important known bugs in it

for 2.13.14, can we switch to making -Ytasty-reader a deprecated alias for -Xtasty-reader?

the context for this is that in both the Scala 2 and 3 worlds, we are trying to create an expectation that -X flags are normal to use and -Y is experimental and/or flaky and/or internal stuff

the Scala 3 project is in the process of removing or renaming as many -Y flags as possible. making this change would IMO also be consistent with our own history of cut back on -Y

@bishabosha @lrytz opinions?

[bishabosha]

does it need to be a flag still? (I agree with changing to -Xtasty-reader - I think its pretty stable at this point)

[SethTisue]

Oh, like it would just be enabled by default? Hmm... yeah, let's discuss.

What's the downside? I guess having the flag means it's always explicit whether you are using it. If it's enabled by default then you could have a Scala 3 artifact somewhere in your dependency tree without even realizing it. But maybe that's actually okay. If the dependency works, then great. If it doesn't work, you'll get an error — will the error always make it clear that a Scala 3 artifact is involved and the TASTy reader is in play?

[SethTisue]

Of course there's real upside as well: if a library author writes their library in the supported subset of Scala 3 with the intent of having it be usable from Scala 2, it's a bummer if they have to tell their users to not only use for2_13Use3 when adding the dependency, but also to add the flag. It's a barrier that's probably one of the factors preventing people from publishing such libraries (I'm not aware of any, are you?).

But when I start thinking about transitive dependencies I get a little nervous.

[bishabosha]

Actually it is likely the user will immediately know if they have TASTy on the classpath because the new classpath loader will prefer tasty files over class files whenever they are available

Edit: right but at present they will get told to turn on the flag.

Any error specifically related to incompatible Scala 3 features is prefixed with some error like "incompatible Scala 3 type" or "unexpected tasty version... this was compiled by Scala 3.5.1"

[lrytz]

the user will immediately know if they have TASTy on the classpath because the new classpath loader will prefer tasty files

That's the case right now, but if we enable the tasty reader by default the compiler doesn't make any noise about reading tasty files.

If a project directly uses a Scala 3 artifact it has to use for2_13Use3, right? How about using a _2.13 library that itself has a dependency on a _3 artifact?

If we actually recommend to publish _3 libraries for use with 2.13, I think the feature should be enabled by default. How is that currently, what does the documentation say? Are there tools for library authors on Scala 3 to ensure their tasty is compatible with 2.13?

[bishabosha]

Are there tools for library authors on Scala 3 to ensure their tasty is compatible with 2.13?

Nothing as far as I am aware, but tasty-query is probably the base to build it on.

There are some subtleties to such a tool if we make one.

Currently the Tasty-reader is designed to be lazy, i.e. it only checks symbols that you actually use in code. So as a whole the scala3-library_3 would fail to meet the standards of "Scala 2.13 compatible", however some parts are necessary for Scala 2 code to interact with basically any data structures, such as scala.deriving.Mirror.Sum/Product being added as parent classes of case class / enum needs to work, (however trying to access an incompatible member such as MirroredElemTypes will fail)

So in this sense what would be a sensible check to enforce?

[SethTisue]

It's unclear whether the TASTy reader will work on the next Scala LTS — it's entirely possible that it won't. Given that, and given that the feature has seen some use but isn't in super wide use, maybe it's better to leave this alone.