wondering if its a good idea to return the default in case an invalid value (not a valid backend enum value) is passed? 🤔

I think get() behaves the same, but in what case a default should be returned then?

Better keep it consistent with the rest of the API I think.

With get, there is no invalid value.

In #48525 there is the same dilemma and the trend is to throw an exception when the value is invalid. This is particularly useful when the value comes from the query string, a BadRequest response is sent when the value is unexpected.

The default is returned when the parameter is not set.

What do you think to add the same parameter $failOnInvalid?
We could even add annotation psalm-assert to narrow the type

$failOnInvalid is added for changing the behaviour while keeping backward compatibility. I think it is better to define a behaviour for all instead of adding options.

If you return the default in case of invalid value, you cannot distinguish when the parameter is not set and when the value is invalid.

the behavior of the method is fixed now:

• we throw an \UnexpectedValueException when the value is not part of the backed enum, and not a string or an int (ie: it could be an array)
• I've overridden the method in InputBag to throw a BadRequestException in that case