-
Notifications
You must be signed in to change notification settings - Fork 149
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
Scala 3: What should be done #300
Comments
The first step towards Scala 3 for any real-world project is cross-compilation between Scala 2.13/Scala 3. Most of the OSS libs added Scala 3 to their cross-builds. IMO, this will be a status quo for the next few years. Only then we'll drop Scala 2 support and migrate to the new enums. Thus, the Enumeratum macros should be ported. |
My 2c: we use Enumeratum mostly to model things that map to postgres enums, with a nice benefit of being able to have safe I'm not sure if Scala 3 enums has support for this... |
Fair point; have you checked that the macro(s) in its current form can be ported? A PR would be welcome to start concrete discussions as well. |
Nevermind... looks like support for custom |
@lloydmeta I think you were looking for |
@note Hmmm I think that's almost it, but how do we make the second print resolve |
@lloydmeta Ah, I missed the point that it's about custom names as I mostly looked at scastie session using outdated |
any plan to have the macros ported? |
The plan is:
Currently stuck on (1). |
There is some dotty/scala3 issue about that? Alternatively, could we change the signature of
Sorry if this, does not make sense at all, because I am not very familiar with macros... |
Nope. I think it was a conscious decision/redesign around the Scala 3 macro system.
It's not so much a problem of having to provide the type param (the compiler can figure that out in the same way I think), just AFAICT, the functionality to explore the I think one way might be to change it into something that works on a defined scope like so, but it's not backwards-source compatible. sealed abstract class Light extends EnumEntry
@findEnumValues // or find members at this point
case object Light extends Enum[Light] {
case object Red extends Light
case object Blue extends Light
case object Green extends Light
} To be clear: the only helpful next step in this issue is for someone to come forth with a working prototype. |
Actually it's possible to access "enclosingModule" via |
@marq Thanks so much for that (even including a Scastie!). I'm very unfamiliar with the new Scala 3 macros (and it seems like the documentation may not be the most complete ?) so I'm having a hard time and would really appreciate the help of those who are such as yourself 🙏🏼 To provide a clean sandbox to hack around, I created a separate repo to explore porting macros to Scala 3 some more, and split it into 3 issues, one for each main macro method: https://github.com/lloydmeta/mune/issues Since you've done most of the work, lloydmeta/mune#1 is basically done, but I'm running into some errors on lloydmeta/mune#2 (materialising the companion object of an enum entry type); wondering you can spot anything wrong there. lloydmeta/mune#3 is also a TODO. |
Hi @lloydmeta ! It seems that enumeratum still provides stuff that native scala3 enums don't, does it? Would be great to have I guess. |
Hey there @mauhiz , yeah, it turns out there are some things missing from the official Scala 3 enums that is supported here. I agree it would be nice to have, but I got stuck in my attempt to port the macro to Scala3 (see #300 (comment)). I'm not actively working on it and any help would be appreciated :) |
Thanks to @tpunder, the Scala 3 port is mostly complete. The remaining bit is lloydmeta/mune#3, which involves porting over this bit enumeratum/macros/src/main/scala/enumeratum/ValueEnumMacros.scala Lines 85 to 117 in d91d191
I think the main tricky bit is finding how to destructure the different ways to declare |
@lloydmeta any update on this? Thanks |
There's a PR open (#349) that I've slowly been reviewing over iterations. |
Done. |
First off, thank you. Second, I notice that there are two separate libraries: one for scala 3 and one for scala 2. Is there any plan or desire to have a mixed library that can be used in scala 3 and in scala 2? This would be useful for large projects that use enumeratum that want to migrate to scala 3 gradually. I think the alternatives would be either migrating all at once, or depending on both libraries, and I don't know how well depending on both libraries would work out in practice (I imagine not well) |
There's no plan, but it does sound desirable; do you want to give it a stab ? |
Sure, I'll take a stab at it |
I have something that I think would work, but there's a bug in the macro mixing functionality that is triggered by using type parameters from the class level in a scala 2 macro call. So I don't think any further progress can be made until that's fixed. branch: |
Looking at Scala 3, the enumerations built into the language look pretty good.
The questions are
enumeratum
look like in a Scala 3 world?The text was updated successfully, but these errors were encountered: