Lloyd

Ugh, I think the reason this is happening is because we need to check for `value` being implemented as a literal on `Day` when expanding `findValues`, but in this case,...

Any design should take into consideration the design proposed here https://github.com/lampepfl/dotty/issues/1970

Strange, I've not seen this in my usage of Enumeratum per se, but I have seen something similar when I've had cyclic dependencies between different objects. I don't remember the...

@sergey-tikhonenko can you throw that in a repo? Much easier to take a look then.

Cool, thanks for that. I think the culprit is the same as in #138 and #144; classic circular dependency going on between companion object and class init. I've submitted sergey-tikhonenko/org.sandbox.enumeratum#1...

@mlvn23 interesting; would you happen to have any dependencies (references to each other) amongst the different enums? In any case, if you could share a minimised example, it would be...

Hey, Thanks for the feedback :) I'm afraid I don't quite understand how extending `EnumEntry` would help get rid of that piece of boilerplate. Can you show me an example...

@i-am-the-slime ah yeah, unfortunately we can't put `findValues` as a lazy val on the base class because the macro expansion gets invoked, at which point the macro doesn't know what...

I'm not opposed to this in principal, but I think this is a breaking change for situations where an implicit `Encoder[A]` or `Decoder[A]` is expected, since the new implicit `Codec[A]`-generating...

Hey, that sounds reasonable to me. To double check my understanding: the current issue is that the enum in the doobie module basically only supports going to-and-from strings, but not...