The type is not only important for Doctrine but also for the Form type (detecting whether the choice is selected also uses strict comparison). So if you edit an object whch contains the 0.9 value, the '0.9' choice will not be selected currently.

There is (at least) 2 ways to achieve this:

• making the choice use real floats:

  $builder->add('test', 'choice', array('choice_list' => new ChoiceList(array(1, 0.9), array(1, 0.9));

• add a model transformer on your field to convert floats to strings and back (totally overkill for this simple use case though): http://symfony.com/doc/current/cookbook/form/data_transformers.html

@stof Awesome - thank you for the detailed reply. I will try option 1 tomorrow, if it is that easy my issue is solved and I think I will add an hint to the docs.

@stof I can confirm this works as you described it. However when investigating this I found that the Choice Validation Constraint seems not to do a strict comparison. Do you know if this is actually intented?

And it seems there are some type adjustements made. Without digging too much into details I saw this fix within the ChoiceList:

https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/ChoiceList/ChoiceList.php#L462

I guess you might experience only issues with the float type. Thank you again for your support!

@peterrehm this is the choice index, not the choice value

I saw this, but from the tests with it in the actual app there must some casts be going on.

The point regarding validation is clear now. This solely depends on the optional strict option. Therefore it has matched.

As promised I just added a docs PR.

@peterrehm Some more explanation: PHP arrays can only use integers or strings as array keys. Since 0.9 is not a valid integer, it is stored as string and returned to your application as such.

Fixing #4067 will help to solve your problem without having to explicitly create a ChoiceList instance (which will be done internally).

Thank you for the information, I figured this out. So #4067 is definitely a good improvement, it makes it much more intuitive.