What about a more generic choice_filter: <callable> option, covering any choice type and allowing anyone to mutate choices as needed.

I think it's already supported in user land:

$supportedCountries = ['FR', 'ES', 'CU'];

$builder->add('country', CountryType::class, [
    'choice_loader' => new IntlCallbackChoiceLoader(function () use ($supportedCountries) {
        return array_intersect(array_flip(Intl::getRegionBundle()->getCountryNames()), $supportedCountries);
    }),
])

Although I'm not opposed to adding a shortcut for Intl form types.

vs.

$builder->add('country', CountryType::class, [
    'choice_filter' => function ($countryName) use ($supportedCountries) {
        return in_array($countryName, $supportedCountries, true);
    }),
])

or 'choice_filter' => $supportedCountries as a shortcut

just saying :)

See #14072 and #18334

Right, cool :) so i'm not the only one. The feature would be priceless, @sstok WDYT?

That (choice_filter) option would be especially useful for child types that need to filter the choices list built in the parent type, without having to duplicate the logic of the choice_loader, right? Otherwise, it can be done in the same choice_loader option.

Yes or pre-defined choice loaders like Intl. The main advantage is you dont have to (re)define a new choice loader basically. Thus knowing about the labels, etc. In your last example it could just as well be a ChoiceType directly (or at least you dont really rely on CountryType anymore).

In your last example it could just as well be a ChoiceType directly (or at least you dont really rely on CountryType anymore).

Yeah, true :)

I took a deep dive into the Choice loading system, and almost drowned 🦈 !

The way the choices are loaded does not allow for filtering after their list is created, the loader provides a list and only modifying the loader implementation (which is not always possible) would make it possible to filter the choices before the ChoiseList is created.

There is no other option (no pun) but use custom options for each types. But allowing a Closure for a custom filtering (like $k[0, 2] === 'EN') would a good feature, in practice this allows an array of accepted choices and closure to filter the choices (for more advanced use cases).

Edit: I added support for closures.

There is no other option (no pun) but use custom options for each types.

Isnt it possible to add a FilterChoiceList and a decorating choice loader. If the choice_filter option is passed we decorate the choice loader (or use the callback choice loader) and return a FilterChoiceList instead (which also decorates).

@sstok today I can investigate about this choice_filter, do you mind if I make an alternative proposal?

@yceruto Feel free to do 😄 this thing is driving me crazy.

See alternative with choice_filter #28607

Thank you for your engagement in this @sstok! 👍 Do you agree to close here in favour of #28624?

Whoops, a bit late :) yes I agree this can be closed in favor of #28624