Scala 3.4.0-RC1 is available on Maven Central. This time, the changelog is massive. The main areas of improvement include work on quotes, polymorphic functions, deprecation of old syntax, improvements in reporting and linting, and numerous bug fixes.
You can expect the stable 3.4.0 release at the beginning of February.
It’s important to note that the expression compiler and the Scala Native of Scala DAP support have not been released for 3.4.0-RC1 and will be made available in RC2 or later.
This is splendid! Kudos to everyone who put in all the hard work to get 3.4 to this point!
Best feature, personally: having relaxedExtensionImports on by default really makes extensions a first-class feature, with very few exceptions. I’ve been using it extensively to add functionality in a very natural-seeming way, with approximately no overhead, to existing classes (like Array). Not having to worry about collisions across namespaces makes it feel welcoming rather than worrying! For instance, I like to add proper symbols for math to things that naturally ought to have math (e.g. Java Duration, or Int + something of mine) and now they don’t collide. Yay!
Worst “feature”, personally: the 1181 warnings in the code of my primary library from infix notation, plus another 416 warnings from my test suite, are unwelcome. Although "-Wconf:msg=is not declared infix:s" is a workaround, the auto-rewrite is not helpful because the entire reason I’ve used infix is for clarity, often to draw the appropriate amount of attention to the operator, and backticks mess that up. Also, a good deal of my usage is for Java classes (e.g. date plus duration), and there’s no workaround for that aside from suppressing the message. (Scala classes whose methods I like using infix I could lobby to have labeled as such.) Anyway, after all the improvements in legibility from significant whitespace, I’m not excited that 3.4 wants me to make my code more ugly and harder to understand.
(Most everything else: doesn’t affect me or is a welcome change.)
If you think there are things to adjust around the semantics of infix + warnings I’d suggest that you open a Pre-SIP with proposal for changes to open up for further discussions on this. And also in that thread explain why the warning suppression is not enough, etc.
People explained at length why the feature was ill-considered when it was proposed. It’s annoying for exactly the reasons that were already explained and rejected or ignored. Nothing has changed, so why go through the process again?
But with warnings suppressed, it’s a moot point for anyone who likes to use infix notation liberally.
Scala 3.4.0-RC2 is available on Maven Central. This release fixes a regression and contains changes that will smoothen the migration for things that will be changed in future releases, such as given loop prevention or deprecation of explicit arguments for context bounds. The release also brings Scala Native and Scala DAP.
You can expect RC3 very soon. It will contain very minor changes. It is, however, needed to keep our forward compatibility guarantees in the 3.4.0 line.
That is the plan. However, I must admit that it is relatively low on our priority list, so it will get the developer’s time only when there is some break in the more pressing matters.
In the meantime, there is this page with build summaries. Take them with a grain of salt as sometimes a failure may mean that something changed in the project configuration and the Build was not ready to handle that.
10 projects that were green on 3.3.1 are red on 3.4.0-RC2 when built from the same sources
13 projects have their most current version in red on 3.4.0-RC2 but have a previous version that was green on 3.3.1
Each one of these projects needs to be examined individually. It is possible that there are regressions in the compiler, but there is also a possibility that the projects rely on a bug in the compiler that has been fixed. In the latter case, we will need to check if we should recommend a workaround or if the old behavior can be somehow kept without reintroducing the bug.
Thanks for the information. So it seems the number of red projects is increasing with every minor version and even patch versions. We need to aspire to change the course. There are known open regressions, and currently the priority seems to be more on adding features and deprecating “bad features” than stabilization. As a developer that has been following the Scala 3 release milestones and cadence from day 1, at times it feels like hitting a moving target.
So it seems the number of red projects is increasing with every minor version and even patch versions. We need to aspire to change the course.
Yes, it’s true, but we also need to remember that most of possibly source incompatible changes were delayed until LTS versions line was established. We need to remember that new minor release means that there can be some source incompatibilities, and might require some adjustments of the code of users. However, I agree that in patch releases there should be no new regressions.
Some of projects failures in 3.4.x, since 3.3.x are due to the changes in new, more constrained, but more predictable match types. Out of 23 failing projects these issues are present in at least 4 of them. There were provided a fixes or workaround for library authors, but these were either not yet applied, or libraries were not yet released with fixes (by default OpenCB uses projects at their last release revision instead of using main which might be unstable)
Changes to implicit resolution in which order of their definitions in the same file is important now since 3.4, it allows to prevent cycles - 3 projects failing because of this change
Failures in these 2 groups above can be mitigated when using -source:3.3 - OpenCB by default tries to build them with -source:3.4-migration to mitigate incompatibilities or deprecations that can be handled by the compiler itself undef migration mode.
Next area is fixed detection of incorrect syntax, eg. positional arguments after named ones, invalid usage of experimental annotation, pattern bindings with refutable extractor - at least 3 projects.
There is a number of regression present in RC2, but fixed in RC3 or nightly versions - 4-5 projects
Finally, some projects are failing to due imperfections of Open CB allowing to make it generic enough to work with almost 1.5k projects., there are at leat 3 of them and it’s due to some of the recent regressions in OpenCB itself.
There is a set of projects which are known to fail: e.g. jsoniter-scala uses a recursive match types in one of it’s test sources - these are not allowed, and should result in compilation error, but unfortunately these started to crash compiler some time ago - mostly because of their complexity, most of other match types give a normal compilation error.
The remaining projects ~6 might be an actual regressions, these are in most cases reported and minimised, but don’t not fixed yet. There might be multiple reasons to that - e.g. fixing them can break other stuff.
Apart from what was already greatly explained by @WojciechMazur above, it is essential to add that I’ve said nothing about fixed regressions. Those are not clearly visible in the reports, but from a quick look, I can see at least one library that stopped compiling between 3.2.2 and 3.3.0 but started passing compilation again in 3.4.
It is true that 3.4 increases (temporarily) the number of regressions. It will come down in patch releases. Also, it is worth mentioning that 3.3.2-RC1 came without any regressions (according to the CB), and 3.3.2-RC2 will not be different.
3.4.0-RC3 and RC4 are ready for testing! Both compiler versions were available on Maven Central for a few days already. I was waiting with the announcement until we were sure that there were no problems in tooling directly using the compiler.
RC3 fixes the minor forward compatibility issue mentioned earlier and aligns the context bounds treatment under the -3.4-migration setting with the standard behavior.
RC4 is identical, but it bumps a version of jsoup - a dependency of scaladoc. The previous version was affected by a CVE. Copying my comment from the 3.3.2 thread:
The mentioned CVE is CVE-2022-36033 . In our case, it is absolutely not exploitable in any way. However, we treat such things seriously, so we decided to release 3.3.2-RC3 and 3.4.0-RC4, being identical to the previous release candidate but having jsoup dependency bumped to not vulnerable version.
