Scala 3 migration

[benhutchison]

Dotty-compatibility mode provides a way to use mouse now in Scala 3 projects, eg ("org.typelevel" %% "mouse" % "0.25").withDottyCompat(dottyVersion)

However, Scala 3 migration is also a good time for any major refactors of the lib. Im thinking about a Scala 3 only version which would allow a clean break.

• [x] Top level values and extension methods
• [x] Dropping any obsolete methods that are now in core
• [x] Move to munit for testing (just for the simplicity)

If you have any ideas/requests for a Scala 3 rewrite, please add them to this issue

[benhutchison]

https://github.com/typelevel/mouse/pull/182

Also @katlasik note that scalacheck is gone in the Scala 3 version

[benhutchison]

Hi @danicheg Not at all urgent, but Id like to do a zoom meeting with you sometime to talk about Scala 3 strategy for mouse. There were some non-obvious things I discovered when porting mouse to pure scala 3 that it'd be good to show-and-tell via a screenshare. Can you email me at [email protected] some time..

[danicheg]

Good idea, @benhutchison! I've left a comment about Scala 3 migration in your PR, but I will repeat my thoughts here too. I propose to have one main branch and introduce a new syntax powered with extension methods in Scala 3 source directory (as I've done in #248 for tuple syntax for Scala 2 only).

[benhutchison]

Scala 3 src directories could work... 🤔

• In my Scala 3 branch, there was a nice surprise: the need for whole js src tree went away completely when switching to extension methods and export instead of package objects and syntax traits. The root of the need is we offer some extensions for java.net.Urlon jvm only. But the way package objects work in 2.x means two versions of package are needed, with different traits mixed in. Whereas in 3.x, it's a strictly "additive" model where you can just declare all extensions independently, both shared and platform-specific, and they get rolled together and exported.

• I also did a deprecation cycle in the branch. Methods have been added to core, and conventions have emerged, that didnt exist when mouse was first created. Eg Users should be nudged to move off right and left on Option since toRight/toLeft in core work perfectly well now. parseDoubleOption and friends on String is obselete now that core offers toDoubleOption etc. There's an emergent convention to to<X><Y> for String conversions where X=payload type (eg Boolean) and Y=container (Option, Either etc) I moved to, dropping mouse's parse prefix.

• I threw out ScalaCheck. It always seemed like over-engineering in mouse, which is all about syntactic convenience. If a method is complex enough to need property testing, it probably belongs somewhere other than mouse.

• Finally, I think one of mouse original "design goals" - to ease source compatibility between Cats and Scalaz - has largely gone away. Should probably remove from readme.