Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promote -Ytasty-reader to -Xtasty-reader? #862

Open
SethTisue opened this issue Feb 21, 2024 · 8 comments
Open

Promote -Ytasty-reader to -Xtasty-reader? #862

SethTisue opened this issue Feb 21, 2024 · 8 comments
Assignees
Milestone

Comments

@SethTisue
Copy link
Member

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?

@SethTisue SethTisue added this to the 2.13.14 milestone Feb 21, 2024
@som-snytt
Copy link

👍 although we might need to call it tastx. I did not realize it was -Y for flakY. Offering my feedback unsolicited.

@bishabosha
Copy link
Member

bishabosha commented Feb 21, 2024

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

@SethTisue
Copy link
Member Author

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
Copy link
Member Author

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.

@som-snytt
Copy link

Dale made boolean flags that can default to true, so you could -Xtasty-reader:false if you need to turn it off.

@bishabosha
Copy link
Member

bishabosha commented Feb 21, 2024

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
Copy link
Member

lrytz commented Feb 22, 2024

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
Copy link
Member

bishabosha commented Feb 22, 2024

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 SethTisue self-assigned this Mar 16, 2024
@SethTisue SethTisue modified the milestones: 2.13.14, 2.13.15 Mar 16, 2024
@SethTisue SethTisue modified the milestones: 2.13.15, 2.13.16 Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants