Hi! Can confirm I can reproduce it. The problem happens when choices array is a string-keyed array. Giving

public const ALL = [
        'enum.format.example1',
        'enum.format.example2',
        'enum.format.example3'
    ];

Works just fine.

If your possible solution works fine, you should definitely create a pull-request 👍 !

My solution is a hack, someone could use a choices array with a key named "multiple" thus breaking this constraint again. There is no real solution to support both attribute and annotation.

Here I tried to reintroduce $value in the constructor ; there is one missing case, but this time using choices: forces the constraint to get that this cannot be merged with options:

    public function __construct(
        $value = null, // <--------------------------------- reintroduce "value" before "choices"
        $choices = null,
        // ...
    ) {
        
        if (\is_array($value)) { // <----------------------- @Choice({...}) or #[Choice([...])]
            if (\is_string(key($value))) { // <------------- @Choice({"min":1}) or #[Choice(['min' => 1])]
                $options = array_merge($value, $options); // @todo this does not eliminate the possibility of an associative array as choices
            } else {
                $options['value'] = $value; // <------------ @Choice({"foo","bar"}) or #[Choice(['foo','bar'])]
            }
        }

        if (null !== $choices) { // <----------------------- @Choice(choices={...}) or #[Choice(choices: [...])]
            if (null !== $options['value']) {
                throw new Exception('You cannot use both "value" and "choices" in ' . self::class);
            }
            $options['value'] = $choices;
        }

        // ...
    }

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Hi! Yes this is still relevant. My workaround was to create a new choice constraint extending the current one but removing the faulty compatibility layer between Annotation & Attribute.

I get that this is not a priority at all, but at least consider adding a note in the Choice constraint documentation stating that support for array was removed in favor of list<string>:

https://symfony.com/doc/current/reference/constraints/Choice.html#choices

Are you able to submit a PR that fixes the problem?

Hi @derrabus , I tried to find a way but could not find a real solution to fix this and cover all use cases. There is always an edge case. You added an if in the Choice constraint to make it a valid PHP Attribute and Annotation at the same time:

if (\is_array($choices) && \is_string(key($choices))) {
    //                      ^
    //                      +- this removed support for a string indexed array of choices
    //
    $options = array_merge($choices, $options);
} elseif (null !== $choices) {
    $options['choices'] = $choices;
}

Merging $options is required to support both attributes and annotations without a good way to detect if $choices really was meant to contain choices or options. We could check is_string + is in a list of valid option name but what if people really want an option with a key named multiple.

In short, it's a niche problem.

For people stuck with this, maybe use this simple hack #[Choice(options: ['value' => YOUR_STRING_INDEXED_LIST])]

I see. Using a string-keyed array as choices is indeed an edge case that broke completely when migratng to attributes. With annotations, it was only partly broken. Since the choice constraint does not use the keys, passing a non-list arrays was kind-of working by accident and not really by design.

A possible solution would be to move the $options parameter to position 0 of the constructor signature. This would allow us to enable support for string-keyed choices for attributes with the same limitations as with annotations.

one reason would be to share this constant array with the ChoiceType choices option

The ChoiceType should already make sure that the submitted data is among the configured choices. You would not really need the constraint in that case, would you?

I previously tried to reintroduce a parameter to position 0 but there was still one use case where this wasn't working.

#41508 (comment)

This issue did not get a lot of feedback to really require all our attention. Feel free to close as I already provided workarounds if others were to need them.

abstract class FakeEnum {
    public const ALL = [
        'key.to.translation1' => 'Choice 1',
        'key.to.translation2' => 'Choice 2,
    ];
}

// then validator could use 
#[Choice(FakeEnum::ALL)]

// and form could use
$builder->add('choice', ChoiceType::class, ['choices' => array_flip(FakeEnum::ALL)]);

// the flipped version was also usefull to get translations from values in templates

#44860 would be my take at fixing the issue.