-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
👍 although we might need to call it |
does it need to be a flag still? (I agree with changing to |
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? |
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 But when I start thinking about transitive dependencies I get a little nervous. |
Dale made boolean flags that can default to true, so you could |
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" |
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 If we actually recommend to publish |
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 So in this sense what would be a sensible check to enforce? |
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 itfor 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 stuffthe 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?
The text was updated successfully, but these errors were encountered: