Conflict with Scala 3 enums about enumeratum HOT 5 OPEN

I don't have a hard stance about not making the two compatible, but I do have to wonder about the use case of mixing Scala 3 enums with enumeratum

There's really a use-case. It helps get rid of the need to implement custom codecs every time.

Like, when we use enums in data models, for instance, for JSON responses from some API, or in databases, Enumeratum is super handy. We can have friendly names for each option, but at the same time, we can define keys that match with an external data source. It'll be easier to get what I mean with a code example.

enum TransportMode(id: String): // I need Enumeratum here to make this work (automatically)
  case Truck    extends TransportMode("TRK")
  case Vessel   extends TransportMode("SHP")
  case Airplane extends TransportMode("AIR")
  case Rail     extends TransportMode("TRN")

Thanks to Enumeratum, I can go with StringEnum and deserialize data using the value in id, while still using friendly names in my code. So, I don't have to create an enum with weird values like below and use them in my code. I just want to use them for mapping data.

enum TransportMode:
  case TRK, SHP, AIR, TRN // unfriendly names that also don't fit the code conventions 

And yeah, without Enumeratum, I could achieve the goal by implementing a custom codec. But the cool part is that with Enumeratum, I just elegantly define this mapping, and that's it. No need to write any boilerplate code for a custom codec, or access the id manually in a mapper.

Another use case is when the external source uses screaming case. That's where I'd use with Lowercase as in the example from the first comment. The external system would send in JSON values like BLACK, COLOURFUL, but in my code, I can stick to my style guide and have Black and Colourful.

Continuing from the previous explanation and summarizing the motivation:

After switching to Scala 3, I want to implement my enums slickly using the enum syntax, instead of mixing up conventions. Like, not sometimes using a sealed trait with the whole Scala 2 style (where I want to use Enumeratum), and other times enum. I just want to have consistent conventions throughout the project and always use enum.

I hope the above motivation is convincing enough that Enumeratum is still needed, even though Scala 3 has enum now. It's about making that enum be on steroids.

I don't expect to pick up this any time soon. So whoever reads this, feel invited to pick it up.

Bumping this, need help.

from enumeratum.

Yeah, I'm surprised they didn't make it an IArray (Scala 3's immutable wrapper type for arrays) at least.

I would be interested in trying to fix this in general (experimented a bit yesterday), but my OSS bucket list is considerably long already, so I don't expect to pick up this any time soon. So whoever reads this, feel invited to pick it up.

from enumeratum.

Nice, thanks for bringing this up.

I don't have a hard stance about not making the two compatible, but I do have to wonder about the use case of mixing Scala 3 enums with enumeratum (fwiw I think this wouldn't have worked with Scala 2 either?).

Once we understand that, then we can better discuss whether this is something worth putting in the effort to debug and fix.

from enumeratum.

I don't have a hard stance about not making the two compatible, but I do have to wonder about the use case of mixing Scala 3 enums with enumeratum (fwiw I think this wouldn't have worked with Scala 2 either?).

And I don't have a hard stance on that it should be possible to mix both, but I see some advantages:

• Clearer and shorter syntax than sealed trait
• Scala newcomers are now learning Scala 3 with enum, so it can help the adoption of this library to support it
• Profiting from enumeratum's large collection of integrations with common libraries while using enum

If there's no good way of integrating, I would at least suggest to add a note in the docs as the error can be a bit puzzling for people not familiar with Scala compilation internals.

from enumeratum.

All valid points.

I think the biggest barrier is, as you found, the values: Array[_] that Scala 3 emits : I understand it's probably for Java compat, but I'd rather not have Enumeratum move to that; besides being a bit low-level, emitting a new array is necessary in order to be "safe" (otherwise callers can mutate the thing!).

Not exactly sure where that leaves us, but I'll leave this issue open to see if someone interested (are you?) can take up the challenge of integrating the two.

from enumeratum.