Compile with Scala 3 #166

povder · 2021-12-31T22:33:03Z

Compile with Scala 3. This is a prerequisite: scala/sbt-scala-module#150

povder · 2021-12-31T22:36:17Z

src/main/scala/scala/collection/decorators/package.scala

+  implicit def iterableDecorator[C](coll: C)(implicit it: IsIterable[C]): IterableDecorator[C, it.type] =
    new IterableDecorator(coll)(it)

-  implicit def SeqDecorator[C](coll: C)(implicit seq: IsSeq[C]): SeqDecorator[C, seq.type] =
+  implicit def seqDecorator[C](coll: C)(implicit seq: IsSeq[C]): SeqDecorator[C, seq.type] =
    new SeqDecorator(coll)(seq)

-  implicit def MapDecorator[C](coll: C)(implicit map: IsMap[C]): MapDecorator[C, map.type] =
+  implicit def mapDecorator[C](coll: C)(implicit map: IsMap[C]): MapDecorator[C, map.type] =


Changing these names is required for it to compile with Scala 3 (the name of implicit def can't clash with the existing class). I understand this breaks the compatibility so I'm leaving the decision here to the maintainers.

Options:

Change the names, break the compatibility, don't bump the major version

Change the names, break the compatibility, bump the major version

Change the names only for scala 3 (create a dedicated file for scala 3)

Hello @povder, thank you for your contribution!

Option 1 is not practicable. We have to bump the major version number if we break the binary compatibility.

I am not sure about option 3: I believe it should be safe because the Scala 3 artifacts have no previous release, and users can not depend on both Scala 2 and Scala 3 artifacts in the same build. I wonder if this can create issues somehow, still… Also, I am a bit worried by the introduced complexity on our side.

Last thougth: it would be a good opportunity to move to 1.x.y versions instead of the current 0.x.y.

Thougths?

Thanks for your input @julienrf. My preferred solution is to change the names for both Scala 2 and 3, keep the single file and bump version to 1.0.0.

I don't take it as given that this repo should ever go to 1.0.0. It seems plausible to me that it could stay in 0.x versions forever, with no bincompat guarantees at all.

It depends on whether you see the purpose of this library as making user-contributed code available for use in production, or just to make it available for people to try out so it can be further improved. And I'm not sure we've ever really decided that.

OK, so maybe another solution would be to go with a version 0.3.0, but I wonder what would be the problem of using 1.0.0 instead of 0.3.0? The only issue I see with 0.3.0 is that it won’t be possible to distinguish between a future release that breaks source compatibility and a future release that breaks binary compatibility (they would both have the number 0.4.0).

I'm thinking more of the social aspect than the technical aspect. Version numbers send signals to human beings as well as to tooling, and staying on 0.x indefinitely helps communicate that this repo is just a pile of experimental code that may or may not have been seriously tested or vetted by anybody.

@SethTisue I think people may still expect releases of this lib to be binary compatible on minor version bumps even if it hasn't ever been publicly communicated because versionPolicyIntention := Compatibility.BinaryCompatible is set.

Edit: after re-reading your comment I understand that your point was only about 1.0.0.not about not having a binary compatibility policy.

SethTisue · 2022-01-06T01:03:36Z

This is a prerequisite: scala/sbt-scala-module#150

sbt-scala-module 3.0.1 is on its way to Maven Central

povder · 2022-01-06T01:59:05Z

Okay, updated sbt-scala-module to 3.0.1. The build still fails because of MiMa violations and because sbt-dynver plugin is used I don't think I can bump the version to 0.3.0 as part of this PR. I believe bumping the version will make the MiMa violations go away.

julienrf · 2022-01-08T16:06:25Z

Thank you @povder!

The way to address the MiMa issues is to relax the compatibility intention by changing this:

scala-collection-contrib/build.sbt

Line 18 in 8bbb437

versionPolicyIntention := Compatibility.BinaryCompatible,

to Compatibility.None.

povder · 2022-01-08T20:27:40Z

For some reason I thought that 0.3.0 would be a new major version and so the binary compat promise would be kept but I understand now that it would need to be a 1.0.0.

Are you sure we want to drop the BinaryCompatible setting? It's up to the maintainers but my opinion is this library should continue using semantic versioning.

julienrf · 2022-01-08T21:09:40Z

releasing 0.3.0 would still follow semantic versioning: when the first version number is 0, then the second version number acts as a major number.

Unfortunately, I am not sure we can compile the existing code with Scala 3, so I guess we’d have to break the binary compatibility.

povder · 2022-01-08T21:21:09Z

Ah, ok, so 0.3.0 would be the next major version.

The binary compatibility needs to be broken but if we release this as 0.3.0 then MiMa shouldn't complain and we don't need to change the version policy to Compatibility.None.

My current thinking is:

we don't need to change the bincompat setting if this is going to be released as 0.3.0
the build fails because MiMa complains that the bincompat is broken in 0.2.x series
I can't change the version to 0.3.0 to make the build pass because sbt-dynver is used and I think I'd need to make a tag in the repo or something to change the version
this PR's build check will never pass and the build will only succeed MiMa checks when merged to main and tagged

julienrf · 2022-01-09T08:39:51Z

we don't need to change the bincompat setting if this is going to be released as 0.3.0

No, we do have to change the compat setting because 0.3.0 would be a major release.

the build fails because MiMa complains that the bincompat is broken in 0.2.x series

No, it fails because we told it that we intend to stay BinaryCompatible.

I can't change the version to 0.3.0 to make the build pass because sbt-dynver is used and I think I'd need to make a tag in the repo or something to change the version

For now, we don’t need to change the version, it is okay to use the one computed by sbt-dynver. We just need to adjust the level of intended compatibility (to Compatibility.None).

povder · 2022-01-09T17:06:59Z

Thanks for explaining @julienrf! I misunderstood how MiMa works.

SethTisue

LGTM, wdyt @julienrf ?

julienrf

Overall, the changes look good to me, thank you @povder! However, I think we should either use Scala 3.0.2, or Scala 3.1.2-RC1 with the compiler option -Yscala-release:3.0.

povder · 2022-02-06T20:48:43Z

Overall, the changes look good to me, thank you @povder! However, I think we should either use Scala 3.0.2, or Scala 3.1.2-RC1 with the compiler option -Yscala-release:3.0.

@julienrf I've changed Scala 3 version to 3.1.2-RC1. I had to add -Wconf:cat=deprecation:s compiler option for it to compile. When compiling with Scala 2 -Wconf:origin=scala.collection.IterableOps.toIterable:s is used but it looks like Scala 3.1 doesn't support origin filter so I had to silence the entire category.

SethTisue · 2022-02-06T20:50:52Z

@lrytz is that true about -Wconf in Scala 3? is there an alternative?

povder · 2022-02-06T20:58:48Z

@SethTisue since you're asking @lrytz about -Wconf I'll provide more info.

With -Wconf=cat=deprecation&origin=scala.collection.IterableOps.toIterable:s I'm getting this:

[error] Failed to parse `-Wconf` configuration: cat=deprecation&origin=scala.collection.IterableOps.toIterable:s
[error] unknown filter: origin

julienrf · 2022-02-07T07:57:19Z

Thank you @povder for your continuous effort! I recently discovered that Scala 3 support of forward compatibility is not mature enough (see the release notes). In particular, it requires special support from the tooling side, and that support is not ready yet. There is some work in progress at sbt/sbt#6814.
I am fine with merging this, but we should update to 3.2.0 final before the next release of scala-collection-contrib, and we should make sure the support on the tooling side is ready.

lrytz · 2022-02-07T08:51:43Z

@lrytz is that true about -Wconf in Scala 3? is there an alternative?

yeah, the Wconf filters are not the same between 2 and 3. See scala/scala3#12857.

SethTisue · 2022-02-16T18:56:56Z

thank you @povder!

povder commented Dec 31, 2021

View reviewed changes

povder mentioned this pull request Dec 31, 2021

Add Scala 3 crossbuild #119

Closed

povder force-pushed the scala3 branch from c3c3199 to 9033ce0 Compare January 6, 2022 01:57

povder mentioned this pull request Jan 6, 2022

issues using intersperse in Scala 3 #146

Closed

povder force-pushed the scala3 branch from 9033ce0 to 5e9acae Compare January 14, 2022 23:24

SethTisue approved these changes Jan 19, 2022

View reviewed changes

julienrf reviewed Jan 24, 2022

View reviewed changes

povder force-pushed the scala3 branch from 5e9acae to da811f3 Compare February 6, 2022 20:46

Support Scala 3

77054fa

povder force-pushed the scala3 branch from da811f3 to 77054fa Compare February 6, 2022 20:49

julienrf approved these changes Feb 7, 2022

View reviewed changes

SethTisue merged commit d69d9b1 into scala:main Feb 16, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compile with Scala 3 #166

Compile with Scala 3 #166

povder commented Dec 31, 2021

povder Dec 31, 2021

julienrf Jan 4, 2022 •

edited

Loading

povder Jan 4, 2022

SethTisue Jan 5, 2022 •

edited

Loading

julienrf Jan 5, 2022

SethTisue Jan 5, 2022

povder Jan 5, 2022 •

edited

Loading

SethTisue commented Jan 6, 2022 •

edited

Loading

povder commented Jan 6, 2022

julienrf commented Jan 8, 2022

povder commented Jan 8, 2022

julienrf commented Jan 8, 2022

povder commented Jan 8, 2022

julienrf commented Jan 9, 2022

povder commented Jan 9, 2022

SethTisue left a comment

julienrf left a comment

povder commented Feb 6, 2022

SethTisue commented Feb 6, 2022

povder commented Feb 6, 2022

julienrf commented Feb 7, 2022 •

edited

Loading

lrytz commented Feb 7, 2022

SethTisue commented Feb 16, 2022

Compile with Scala 3 #166

Compile with Scala 3 #166

Conversation

povder commented Dec 31, 2021

povder Dec 31, 2021

Choose a reason for hiding this comment

julienrf Jan 4, 2022 • edited Loading

Choose a reason for hiding this comment

povder Jan 4, 2022

Choose a reason for hiding this comment

SethTisue Jan 5, 2022 • edited Loading

Choose a reason for hiding this comment

julienrf Jan 5, 2022

Choose a reason for hiding this comment

SethTisue Jan 5, 2022

Choose a reason for hiding this comment

povder Jan 5, 2022 • edited Loading

Choose a reason for hiding this comment

SethTisue commented Jan 6, 2022 • edited Loading

povder commented Jan 6, 2022

julienrf commented Jan 8, 2022

povder commented Jan 8, 2022

julienrf commented Jan 8, 2022

povder commented Jan 8, 2022

julienrf commented Jan 9, 2022

povder commented Jan 9, 2022

SethTisue left a comment

Choose a reason for hiding this comment

julienrf left a comment

Choose a reason for hiding this comment

povder commented Feb 6, 2022

SethTisue commented Feb 6, 2022

povder commented Feb 6, 2022

julienrf commented Feb 7, 2022 • edited Loading

lrytz commented Feb 7, 2022

SethTisue commented Feb 16, 2022

julienrf Jan 4, 2022 •

edited

Loading

SethTisue Jan 5, 2022 •

edited

Loading

povder Jan 5, 2022 •

edited

Loading

SethTisue commented Jan 6, 2022 •

edited

Loading

julienrf commented Feb 7, 2022 •

edited

Loading