Scala 3 [draft]

[benhutchison]

Here is my work on Scala 3 support.

2 branch strategy

• master will be Scala 3.x. Aiming for source compatible with existing mouse, save for a few deprecations.
• current master becomes scala2 branch, fixes only

Remaining:

• Pull the examples from the README into a /example subproject that is shared across both branches, link from README. That's to help ensure source compatbility across the rewrite.
• Thinking to wait for the syntax of Scala 3 to stabilize before publishing Scala 3 binaries.

[larsrh]

I would strongly recommend against going 3-only just yet. Cross-building for mouse shouldn't be a problem, no?

[larsrh]

(The suggestion to use withDottyCompat in #149 is not at all a silver bullet)

[benhutchison]

Er, why? The proposal is to go 2 branch, not 3 only..

…

On Tue., 2 Mar. 2021, 7:29 am Lars Hupel, ***@***.***> wrote: I would strongly recommend against going 3-only just yet. Cross-building for mouse shouldn't be a problem, no? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXJZHZ2TB7SWTHIYEKFC3TBP2L3ANCNFSM4XZRAX2A> .

[larsrh]

The problem with a two-branch strategy is that it becomes impossible to ensure that both Scala 2 and Scala 3 builds are on par with features. Essentially, you are forcing every downstream dependency to also use a two-branch strategy.

[benhutchison]

We need to keep in perspective what mouse is: a small, simple and slowly changing api, almost 100% extension methods. Im not convinced mouse should grow much larger. So I think it's unlikely downstream consumers will be greatly impacted if the branches are source compatible.

…

On Tue., 2 Mar. 2021, 7:33 am Lars Hupel, ***@***.***> wrote: The problem with a two-branch strategy is that it becomes impossible to ensure that both Scala 2 and Scala 3 builds are on par with features. Essentially, you are forcing every downstream dependency to also use a two-branch strategy. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXJZB2ZNVSPIIDRSINTB3TBP2YHANCNFSM4XZRAX2A> .

[larsrh]

Downstream consumers, no matter whether they're libraries or applications, will 100% be affected by your proposal. Essentially, even if there is source compatibility (which you cannot enforce if you have multiple branches), there is no clean migration path from Scala 2 to Scala 3 because suddenly users need to make their dependency on mouse conditional on the Scala version. This is very inconvenient and breaks expectations from past Scala migrations.

[benhutchison]

If by "clean migration" you mean, change scalaVersion from 2.x to 3.x in build.sbt and everything else just works, no that will not be possible. But this is a major version jump, the last one was circa 2006, with breaking language changes. Using a different version of a library is not an unreasonable ask of users. A small number of downstream libraries will need version specific logic, but my impression is that mouse's consumers are mainly applications not libs, that run on a single version.

…

On Tue, Mar 2, 2021 at 7:57 AM Lars Hupel ***@***.***> wrote: Downstream consumers, no matter whether they're libraries or applications, will 100% be affected by your proposal. Essentially, even if there is source compatibility (which you cannot enforce if you have multiple branches), there is no clean migration path from Scala 2 to Scala 3 because suddenly users need to make their dependency on mouse to be conditional on the Scala version. This is very inconvenient and breaks expectations from past Scala migrations. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXJZBT6GVRI4AZAF5SYS3TBP5UBANCNFSM4XZRAX2A> .

[larsrh]

Using a different version of a library is not an unreasonable ask of users.

It is unreasonable if there's no pressing need for it. This library (status quo) certainly doesn't use match types or macros or any other features specific to a Scala version. It creates pain for users while giving them no benefit whatsoever in return.

[danicheg]

My two cents about Scala 3 migration.
I like the idea of using extension methods for Scala 3. Also, I think we can have one main branch, and introduce a new syntax for Scala 3 using the same approach as in #248 (use different source directories for Scala 2 and Scala 3). What do you think @benhutchison?