This is on purpose. If you want to get an array, you should useall('foo').
See the deprecation in the body of the method.

This is quite the BC break. Is there a place where we can find the reasoning behind this? There is no explanation in the upgrade notes or the commits.
It would be a nice read while I look for all controllers where I handle array query parameters and add a custom implementation for default values, as such are no longer supported.

This is quite the BC break. Is there a place where we can find the reasoning behind this? There is no explanation in the upgrade notes or the commits.
It would be a nice read while I look for all controllers where I handle array query parameters and add a custom implementation for default values, as such are no longer supported.

It was introduced in#34363. You will find some explanations here! ;)

Only adding the array type will not fix it. the if statement check in the get should be the same as the set function so you should add!\is_array($value)

@nicolas-grekas even if it is deprecated, it can still return an array in 5.3

Sure, but we don't phpdocument deprecated types.

@nicolas-grekas we will need to change that policy anyway. With native return types, we cannot remove the deprecated types from the signature, otherwise we get a TypeError

Only adding the array type in the docblock doesn't fix anything.

This is still a bug and throws a error because it doesn't accept array while it accepts it in the set function.
vendor/symfony/http-foundation/InputBag.php:36

if (null !==$value &&$this !==$value && !is_scalar($value)) {thrownewBadRequestException(sprintf('Input value "%s" contains a non-scalar value.',$key));        }

It should also accept array again because a lot of websites and app are broke now like mine.

It should accept the same as in the set function

vendor/symfony/http-foundation/InputBag.php:77

if (null !==$value && !is_scalar($value) && !\is_array($value) && !$valueinstanceof \Stringable) {thrownew \InvalidArgumentException(sprintf('Excepted a scalar, or an array as a 2nd argument to "%s()", "%s" given.',__METHOD__,get_debug_type($value)));        }

@dvdknaap you need to call nowall instead of get when you want a array

But how to test is given key is array or scalar value.
Let's go with this example:

GET https://localhost/?q=aGET https://localhost/?q[]=a&q[]=b

First case you can get only through$request->query->get('q');
Second case only through$request->query->all('q');

I can't see a way how to test isq parameter is scalar or array (except catching exception of course)

I also think this leads into some strange cases now specially when working with the FOSRestBundle which is setting the JSON Content to$request->request via theBodyListener. I would had understand if it go strict to string now as from the http specification but instead now float, int are allowed but no array feels strange.

This breaks my code guys. Bad form.

a deprecation breaks your code?

But how to test is given key is array or scalar value.

you mostly know what your application expects

getting the raw value is done usingall()['key']. Please open a doc PR if it's unclear.

@ddr5292 And another one, also broke my code on a minor dependency update. For anyone searching for this on the internet, if you getSymfony\Component\HttpFoundation\Exception\BadRequestException: Input value $key contains a non-scalar value. in /vendor/symfony/http-foundation/InputBag.php:37 you have a controller doing$request->json()-get($key) somewhere in your code on an array. Replace it with$request->input($key) (for Laravel).

But how to test is given key is array or scalar value. Let's go with this example:

GET https://localhost/?q=aGET https://localhost/?q[]=a&q[]=b

First case you can get only through$request->query->get('q'); Second case only through$request->query->all('q');

I can't see a way how to test isq parameter is scalar or array (except catching exception of course)

I cannot agree more with you. I useget() for all type of data. but now it all mess up. The worst thing is that I cannot see the reason why it worth even introducing a breaking change. User submitted value could be very unpredictable. Sometimes it's on purpose and allowed to input either a scalar value or an array. What we need is the flexibility in the back-end to handle it.

This ship sailed long ago. As you can see, this has been discussed numerous times 2 years ago, so it's unlikely that the outcome changes now. Furthermore, both deprecation and new behavior has been part of Symfony for nearly 4 years. Changing or reverting now is impossible and will impact more applications than changing this in existing applications that are upgrading to 5.x or 6.x now.

Please also do not comment more or less the same things across multiple issues/PRs within the same topic. This divides the same discussion across multiple places, making it harder to track.

I'm locking all of those issues now. If there's something NEW to discuss, please open a new issue.