65 posts later, I feel compelled to reiterate this in stronger terms. This is a crucial motivation problem, and it remains largely unaddressed. I'm pretty convinced we've explored just about all the design space there is, and we're converging on the best possible anon enums design other than "do nothing" or "do
enum impl Trait instead", so it's probably time to stop putting off assembling a serious case for "is this better than 'do nothing' or 'do
enum impl Trait instead'?"
The only concrete motivating examples I've seen raised in this entire thread are typical error handling ones, which are exactly where
enum impl Trait is not only conceptually simpler but also nicer for readability and writability. To make a compelling case here, we need to be talking about examples that aren't error handling and/or that require you to care about listing out or matching on the error variants, yet a regular enum is somehow not good enough. I consider it obvious that some of these cases exist, and that it's trivial to whip up contrived toy cases, but I don't currently believe they're common or painful enough to justify even a tiny language change, much less one this big. If I'm wrong, then we need to see more.