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

Scala3 style imports #4677

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

satorg
Copy link
Contributor

@satorg satorg commented Nov 15, 2024

Removes runner.dialectOverride.allowStarWildcardImport = false from .scalafmt.conf then applies scalafmtAll.

UPD.: also re-enables "-Xsource:3" for algebraCore and algebraLaws.

@satorg satorg added the behind-the-scenes appreciated, but not user-facing label Nov 15, 2024
@satorg satorg self-assigned this Nov 15, 2024
@satorg
Copy link
Contributor Author

satorg commented Nov 16, 2024

Looks like it is failing because in #4478 the "-Xsource:3" option was disabled for algebraCore and algebraLaws with the following commit message:

Workaround binary-compatibility issues

🤔

@satorg
Copy link
Contributor Author

satorg commented Nov 16, 2024

Hi @armanbilge,
Do you remember by chance what was the issue with "-Xsource:3" in #4478? I re-enabled it in this PR and all the checks seem passing. Do you think it is safe to leave "-Xsource:3" enabled then?
Thanks!

@armanbilge
Copy link
Member

Huh, that surprises me. I do have a vague recollection of the issue, I believe it related to some methods that were lacking an explicit type, and under -Xsource:3 the type inference works differently, so this would break binary compatibility. And adding an explicit type is impossible, because the binary-compatible explicit type is different for Scala 2 and Scala 3.

If CI is happy, it's probably okay now (?) but it would be really good to understand why ...

@satorg
Copy link
Contributor Author

satorg commented Nov 16, 2024

Yes, it is puzzling quite a bit.. I'm going to convert this Draft to a complete PR and let it stay that way for a while.
Just in order to collect more thoughts and opinions on that and allow some time for pondering all the implications.

@satorg satorg marked this pull request as ready for review November 16, 2024 07:19
@satorg
Copy link
Contributor Author

satorg commented Nov 24, 2024

@danicheg @armanbilge does it make sense to proceed with this, wdyt? I personally feel, yes, it does, since it could be yet another step towards Scala3 syntax migration, but I wouldn't like to run ahead of the train anyway.

Just to keep things connected: there's another PR (yet draft) in the same direction: #4673 by @xuwei-k, which I'd really love to have merged once it's ready.

Copy link
Member

@danicheg danicheg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this requires an accepted tactic among the team. Currently, we have a coherent Scala 2 codebase with few provisos. Personally, I'm in favour of keeping that order of things as long as possible. Cats is a Scala 2 project cross-compiling to Scala 3. I don't think braiding the syntaxes of these two languages would make sense. But that's an interesting approach, indeed. What if they invented a strategy to turn Scala 2 syntax into Scala 3 one day?

@satorg
Copy link
Contributor Author

satorg commented Nov 27, 2024

What if they invented a strategy to turn Scala 2 syntax into Scala 3 one day?

Hmm.. I don't know. For now it looks like Scala3 is moving in the opposite direction – it keeps gradually deprecating Scala2 style syntaxes from version to version.

My point is that if Cats already has -Xsource:3 enabled by default and rewrite.scala3.convertToNewSyntax = true configured in .scalafmt.conf, then why to hold on imports? Imo, recent versions of Scala2 were equipped with -Xsource:3 for the sake of gradual migration rather than do-everything-at-once approach.

@armanbilge
Copy link
Member

I think this is the right direction. It seems to me that a lot of the syntax changes from 2->3 are addressing various "warts" (see also #4673). I think it's great that these improvements are being backported to Scala 2.

My only hesitation with this PR is trying to understand what was breaking bincompat previously, and why it no longer is, see #4677 (comment). I guess it shouldn't be a blocker, I would just feel better knowing why 😅

@joroKr21
Copy link
Member

Could be about different type inference when overriding a method from the superclass

@satorg satorg force-pushed the scala3-style-imports branch 2 times, most recently from 56c3147 to 79ecda4 Compare December 24, 2024 21:32
@satorg satorg force-pushed the scala3-style-imports branch from 79ecda4 to 6ef3e78 Compare December 25, 2024 07:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
behind-the-scenes appreciated, but not user-facing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants