Thanks all for the feedback and questions. I’ll try to get back to some of the comments and answer some questions here.

Before that, I’d like to mention again that Enumeratum strives to be easy to migrate to from the standard lib’s Enumeration, and be easy to use and understood. This is why the main way of using it revolves around using inheritance, and why out of the box, core contains mixins for manipulating enum entry names (a kind contribution from users who are actively using Enumeratum in industry and were tired of boilerplate).

As a result, I don’t see the following happening any time soon, especially because there are already partial function versions of them available side by side that users can choose to use if they wish.

Also, I’d rather make withName and withValue explicit partial functions (ie. functions returning Option[Value]).

That said, there are other ways to use enumeratum that do not involve inheritance and mixing in framework functionality into the enum. I hope this answers @julienrf and @Fristi 's questions (boils down to “would it be possible to define an enumeration in a project and then to get a QueryStringBindable instance for this enumeration, in another project that uses Play (but without modifying the project that defines the enumeration)?” ).

First, note that an Enum is type parameterised by its EnumEntry , so there is a materializeEnum implicit def on Enum (again, another awesome contribution from a user), enabling you to do stuff like this:

def findEnum[A <: EnumEntry: Enum](v: A) = implicitly[Enum[A]]

I’ll leave it to your imagination what you can do with something like that.

Now, for integration libraries, all of them revolve around building instances for typeclasses declared in frameworks anyway. And while it is true that the readme only introduces how to use them using inheritance, everything that is built via inheritance is actually delegated to plain-jane functions. So here goes a demonstration (I hope ammonite is ok):

Loading... Welcome to the Ammonite Repl 0.8.1 (Scala 2.12.1 Java 1.8.0_101) @ import $ivy.`com.beachape::enumeratum:1.5.6`, enumeratum._ import $ivy.$ , enumeratum._ @ // Declare your framework-free enum which you can publish with just a single dependency on Enumeratum @ { sealed trait Greeting extends EnumEntry object Greeting extends Enum[Greeting] { val values = findValues case object Hello extends Greeting case object GoodBye extends Greeting case object Hi extends Greeting case object Bye extends Greeting } } defined trait Greeting defined object Greeting @ // Then in your other projects where you use a lib like Circe, or a framework like Play, just instantiate typeclass instances-adhoc @ import $ivy.`com.beachape::enumeratum-circe:1.5.6`, enumeratum.Circe, io.circe.syntax._ import $ivy.$ , enumeratum.Circe, io.circe.syntax._ @ @ implicit val encoder = Circe.encoder(Greeting) encoder: io.circe.Encoder[Greeting] = enumeratum.Circe$$anon$1@2bcaec2e @ Greeting.values.foreach { v => println(v.asJson) } "Hello" "GoodBye" "Hi" "Bye"

That was for Circe, for Play there is this function which builds a typeclass instance of a Play Json Format for you. The other integration libraries have the same style. Note that we are now talking more so about how the optional integration libraries work with enumeratum-core…

One more question actually: is it possible to have a polymorphic enumeration type?

No, not at the moment. That said I’m not opposed to the idea of doing something like that if it can be implemented well.