Doesn't the parameter bag have all those fancy get*() methods for this purpose?

There's no getString() or/and getArray() 😄

There's no getString() or getArray() 😄

If this is what you're missing, why don't we add those?

If this is what you're missing, why don't we add those?

because people are already using get() as getString(), you can check this by a simple search in GitHub : https://github.com/search?l=PHP&q=%24request-%3Equery-%3Eget%28&type=Code

this can ( and already does ) cause issues :

$term = $request->query->get('q');
if ($term) {
  $results = $repository->search($term);
} else {
  $results = [];
} 

...

class SomethingRepository
{
   ....
   public function search(string $term): array

app.wip/search?q=foo

works

app.wip/search?q[]=foo

500 error, should be 400 instead :)

I understand what you're trying to accomplish. But right now, you're deprecating the only way to access the raw value of an item inside the bag.

It highly unlikely that you would request raw value, not knowing its type. i suppose we can add getRaw(), but its possible to access raw value using $request->query->all()['foo'] ?? $default

It highly unlikely that you would request raw value, not knowing its type.

It might not be the common case, but it has to remain possible.

Please don't deprecate things that work. Changing for the sake of strictness must be worth the trouble it will incur on the community.
Here, the solution is known: make a stricter child class and use it when applicable.

@nicolas-grekas @derrabus what are your thoughts about adding more strict validation in the specialized methods like ->getInt().

Because right now:

// URL: /test?a[]=5&a[]=6

assert(1 === $request->getInt("a"));

seems like a bug to me. wdyt?

PS: I am not talking about the general ->get(), only about ->get{Alpha,Digit,..}()

@apfelbox Those methods simply wrap ext-filter. I agree that the behavior of that extension is not ideal. A better/stricter input validation layer could be worth investigating.

There's no getString() or/and getArray() 😄

And better if there are isString() or/and isArray() so we can do logic to use get($key) or all($key). This deprecation relies on the developer to know that a key would always be string or array, while in reality it can be either and it's up to the developer to do due diligence to perform the checking.

This deprecation relies on the developer to know that a key would always be string or array, while in reality it can be either and it's up to the developer to do due diligence to perform the checking.

You should always know what type of input you are expecting, if you are expecting a string, use ->get('name'), if an array, use ->all('users').

note: ->all('users') already throws an exception if case users is a string.

In some rare cases, you might be expecting an array or string ( you should probably move to using arrays always in this case ), but you can still do:

$input = $request->request->all();
$users = $input['users'];
if (is_string($users)) {
  $users = [$users];
}

// $users is known to be an array.

If the client passed you the wrong type in production, you will have a deprecation message that you should just ignore, as Symfony 6.0 will throw an exception to the client ( bad request ).

see symfony/symfony-docs#13543

In the following code

/**
     * Sets an input by name.
     *
     * @param string|array $value
     */
    public function set(string $key, $value)
    {
        if (!is_scalar($value) && !method_exists($value, '__toString') && !\is_array($value)) {
            trigger_deprecation('symfony/http-foundation', '5.1', 'Passing "%s" as a 2nd Argument to "%s()" is deprecated, pass a string or an array instead.', get_debug_type($value), __METHOD__);
        }

        $this->parameters[$key] = $value;
    }

• The phpdoc talk about string|array
• The deprecation talk about string|array
• The code is checking for scalar or array.

What is the truth ? Is it deprecated for any non-string value or any non-scalar value ?
If someone use ->set('foo', false), does the code should be updated ?

@VincentLanglet scalar values can be cast to string when strict_types=1, that's why it was allowed as far as i remember.

Just found a @nicolas-grekas comment

all is_string() checks in the PR are too strict, we want to accept any stringable:

is_scalar($v) || is_callable([$v, '__toString'])

So I assume the phpdoc should be updated

no, it should still support array as of symfony 5.x, in symfony 6.0 the signature can change to set(string $key, string|Stringable $value)

set(string $key, string|Stringable $value)

If so, the check should be is_string, because scalar won't work anymore
http://sandbox.onlinephpfunctions.com/code/d23a9fa709a138bc57012a7b9e358705e4c441b7

it will if strict_types is set to 0, set used to accept mixed, since we want to keep the deprecation "soft", we wanna to still allow scalar values at runtime ( https://3v4l.org/7W8Y9 ), but statically, it suggest string, which is more correct.

If this is what you're missing, why don't we add those?

because people are already using get() as getString(), you can check this by a simple search in GitHub : https://github.com/search?l=PHP&q=%24request-%3Equery-%3Eget%28&type=Code

this can ( and already does ) cause issues :

$term = $request->query->get('q');
if ($term) {
  $results = $repository->search($term);
} else {
  $results = [];
} 

...

class SomethingRepository
{
   ....
   public function search(string $term): array

app.wip/search?q=foo

works

app.wip/search?q[]=foo

500 error, should be 400 instead :)

I used get() for all type of value. I don't know the purpose of this change. It's now breaking all my codes. Please enlighten me or show me a case that why it worth introducing breaking changes.

As for the above given example, I cannot figure out your purpose of showing that. But to me, the demo code itself is wrong. Why? because the programmer should always validate the input value and make sure it's the desired data type before calling the search($term)

Additionally, sometimes programmer would like to allow front-end submitted value to be either a string or an array, and then handle it differently in the back-end. But after this breaking change, it becomes impossible to do that.

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.