This implementation looks very opinionated to me, thus I don't think it belongs to the Symfony Core asis (but that's only my opinion) :/

For instance, in https://github.com/Elao/PhpEnums, we chose to not use reflection to automatically guess enum values, because some constants can be used to combine values (in case of the FlaggedEnum for instance). (<-- but we do provide more opinionated features based on traits now, so everyone can use it the way they like, including autodiscovering enum values from public constants)
The validator shipped with the library uses the same validator as Symfony Choice's one, but with a different constraint class allowing to choose the method to use to select allowed values (using the callback option, or a list of allowed values).

@ogizanagi It is opinionated - no argue there. Our common practice is to use dedicated enum class for enumerations and we have noticed that it is common practice for others as well -> considering that there is a lack of native enum support.

In order to have enumerations in project, I don't like idea to pull down whole library, especially having in mind that flagged enums are edge case (i want banana, not gorilla holding a banana, in the forest). Especially I don't like idea of inheritance and implementation of enum interface with several methods -> when I only need an enumeration of several possible values. Just enumeration.

Now, having in mind that I have simple final class with enumerations only, naturally, I will benefit of this option in validation.

Wether will this be part of Symfony core is a question about common practice widespread between users: do they use enum classes at all, if they use them, do they use vendor libraries and inheritance or they create a simple class with enums only?

Answers on those question can provide you/parties in charge if this is a good idea or not.

We only created this package because we deal with enums the same way across projects a lot and having clear interfaces eases integrations. We don't always use all the bananas indeed 🍌

But to me, the simplest way to deal with enums is a class per needs, with static methods to get allowed values. Then, use the callback option from the Choice constraint.

Here are my 2 cents 😄

This feature would be nice to have in a custom package. While the name is incorrect, this package allows you to translate enum values to human friendly texts via enums that are built the same way: https://github.com/hostnet/entity-translation-bundle

Shameless plug : https://github.com/greg0ire/enum

My fear with this proposal is that we're trying to implement something that PHP doesn't support natively, so we may be overstepping here.

By the way, isn't an enum a choice with a predefined set of values? Can't we use the existing choice instead?

@javiereguiluz the issue is referencing the values from a non-form piece of code. People want to be able to define the set of values from outside the form, in their domain, and then reuse that set of values in the form.

@javiereguiluz this proposal is very opinionated and base on our usual coding practice.

We have noticed that, in majority of libraries that we use, similar practice is used as well -> final classes with private constructors and constants are used as enum data structures.

Also, we have noticed that we, and others as well, do a lot of copy/paste coding which can be prevented with this kind of implementation.

The question here is not wether this proposal is opinionated or not, or if it is supported natively by PHP or not, we know answers on those questions.

Question is here if this is going to add value to library and improve developer experience, and possible answers are:

• Yes, this is common practice among developers, this will increase productivity and developer experience, it will be useful and used
• No, this is not common practice among developers and this would be used by minority of developers, so it is not worth of maintaining it and supporting

Thats it. If you are going to dismiss it solely because it is opinionated or not supported natively by PHP - there is no need to argue there, this is opinionated, enums are not natively supported, you can do that right away!

However, if developer experience and usability are in game - than, it should be reconsidered from that point of view only.

@greg0ire Yes, we use that "enum" for entity(es), form(s), validator(s), translation sentences (twig) -> same single enum is one single "source of truth", that is our common practice.

Moving to 4.1. Rebase on master might be needed, where PHP 7.1 features can be used btw.

@nicolas-grekas In general this idea of this PR is solid and it will be merged when PR is updated?

I agree with the other commenters that this is very opinionated and I don't feel like this should be part of Symfony core as is. Thanks for proposing.