Basic usage:

$builder->add('locales', LocaleType::class, array(
    'choice_filter' => function ($choice) use ($userLocales) {
        return in_array($choice, $userLocales, true);
    },
));

$builder->add('entities', EntityType::class, array(
    'class' => \AppBundle\Entity\Issue::class,
    'choice_filter' => function ($choice) use ($user) {
        return $user->canHandle($choice);
    },
));

Tests added.

This is a full BC implementation.

The only thing that should be noted in UPGRADE is that someone uses its own ChoiceListFactory should either implement FilteredChoiceListFactoryInterface or use the FilteringFactoryDecorator to use the new choice_filter option, otherwise it will simply be ignored.

@stof any thought on this one regarding the previous (wrong) implementation ?

ping @webmozart :)

@HeahDude this will have to wait until 3.2. We are already in the 3.1 feature freeze, and there is still too much to evaluate about this feature to merge it now (we are not yet fully freezed as we allow us to include some PRs which are ready but not yet merged, but this feature cannot be considered as ready yet IMO).
So I will focus on the review of other PRs for now (the ones still considered for inclusion in 3.1) and come back at this feature later.

@stof I absolutely agree ;) Thank you for your feedback!

Status: Needs Work

@HeahDude : What about accepting an array in the choice_filter option?

The following:

$builder->add('locales', LocaleType::class, array(
    'choice_filter' => $userLocales,
));

will automatically generate the callable using in_array.
It'll help when the type is configurable from a configuration file for instance (like in EasyAdminBundle).

will automatically generate the callable using in_array.

I like the idea, thanks! I'll try to implement it soon when revisiting this one.

@ogizanagi Just curious why not simply use the choices option of the ChoiceType in this case?

I expected this question 😅

This allows to blindly filter the available values, without caring of the implementation of the type. In a config file, you only want to use %locales% for instance (which only contains values).
Behind, the type has the responsibility to associate the proper labels for instance.

Using the choices option of the ChoiceType forces you to redefine everything.

I think you can already solve this case using a custom type:

class UserLocaleType extends AbstractType
{
    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver
            ->setRequired('display_locale')
            ->setNormalizer('choice_label', function (Options $options) {
                $displayLocale = $options['display_locale'];

                return function ($choice) use ($displayLocale) {
                    return Intl::getLocaleBundle()->getLocaleName($choice, $displayLocale);
                };
            })
        ;
    }

    public function getParent()
    {
        return ChoiceType::class;
    }
}

// Then you can do
$builder->add('locales', UserLocaleType::class, array(
    'choices' => $userLocales,
    'display_locale' => $userLocale,
));

But I agree, the filter option definitely simplifies the implementation though :)

But regarding performances implementing a specific type like in my example may be better.

I agree. Such uses of the choice_filter option will be reserved mainly for countries, locales, languages (...). I doubt it'll have a big impact on performances, but it has a very good one on DX.

Is this really something that will be commonly used? I mean if you need to filter your choices, why don't you just do that when specifying the choices option then?

@xabbuh in case of inheritance there would be no need to define again the choices and we could use the same cached choice list on which to apply the filter.

For the EntityType it would allow to filter choices thanks to dynamic properties or method that could not be used with a custom query builder.

So to me this feature is the right answer to both needs.

@HeahDude Sounds reasonable to me. Do you think you can finish this one?

ping @HeahDude

@HeahDude Do you think you can work on finishing this PR or shall we close it?

Closing this PR as there is no more activity. @HeahDude Feel free to reopen whenever you have time to finish it. Thanks.

See alternative #28607