the scalaz-deriving repo contains a module called deriving-plugin which is completely independent of scalaz and supports shapeless, magnolia, play macros, and scalaz-deriving out of the box.
If the name scalaz in the repo name is literally the reason why people aren’t even bothering to look at what I’ve done then frankly I don’t know what I’m doing here, because clearly everything I say will be ignored?
Enum types are a standard defined concept within Java, and always extend java.lang.Enum. They’re also the only non-primitive type - besides Strings and boxed primitives - that you can switch on.
Not being able to produce java-compatible enumerations is very much an interop issue, and one that prevents the most natural way of expressing certain concepts when writing an API in Scala for consumption within Java.
Currently, the only really effective workaround is to define enums in Java code for an otherwise pure-scala project; which is less than ideal!
This sounds like a perfectly reasonable thing to do in the situation you described and does not require bending the scala language to accommodate this niche requirement.
Not the name so much - but the implication from the name that it’ll require pulling in a large framework as a transitive dependency. I’ll freely admit that I ruled it out for one scala.js project that I was working on, specifically because I needed it to be lightweight.
it’s so lightweight, I don’t even care about scalajs 
Its as much of an interopt issue as you make it out to be. Enum isn’t unique to Java, its just a general language concept (which Java happens to have).
I am just saying that personally, the biggest issues with Enum’s isn’t the Java interopt (because honestly if you want Java interopt right now you can just use Java enum, nothing is stopping you), its the fact there isn’t a standard Scala implementation of Enum in Scala.
This basically means we are including enumeratum in every single Scala project I do at work (and even open source) when I need enums, which frankly is very often.
I think Scala enums should erase to Int and nothing else. Can they not be based on an Opaque type of Int? We can have type safety and efficiency. They might need /deserve a bit of special syntax, but I don’t see they need a complete “feature” of their own.
Hello,
How would I create Java enums in Scala code? Thanks!
Best, Oliver
But the most attractive feature of enums is the warning of incomplete matches, and you don’t get that with opaque Ints and some syntax. You’d have to make the compiler recognize a type with a limited set of values.
Besides, if you make Int opaque, it is forced to be boxed, so you’d have an object reference anyway.
Having an object reference is not too bad. These days, most systems are 64 bit, which is enough to make object references single-word, and using 32 bit types like Int does not gain you much if anything.
At which point I think I find them useless – nearly every time I’ve actually cared about the format, I’ve wanted that underlying format to be String.
(Personally, I like Dotty’s version of enum, and am simply hoping to eventually have access to that.)
There is no real difference as long as long as the underlying type is an opaque one.