[Form] Deprecate passing ints #32821
Conversation
| @@ -79,9 +79,9 @@ public function __construct(?string $name, array $options = []) | |||
| * | |||
| * This method should not be invoked. | |||
| * | |||
| * @param string|int|FormBuilderInterface $child | |||
There was a problem hiding this comment.
All similar changes make sense, but I'm not sure the rest does: passing an int will just work in Symfony 5, thanks to the string type. Ppl that use strict mode won't have a smooth upgrade path that's true, but are we going to ask everyone to make their code "strict" while only some actually need it? Not sure...
There was a problem hiding this comment.
I agree that we should rely on auto casting internally. No need to forbid integers passed from users. See #32066
I don't see what these changes try to accomplish.
There was a problem hiding this comment.
@Tobion , these changes are for the ones calling $form->add(1) from classes with strict types enabled. Once we add string type in 5.0, they will have an error.
But now I see the point of @nicolas-grekas better (we already discussed that earlier): if a user does declare(strict_types=1), it's her responsibility to check that she passes correct arguments, because Symfony is not strict about types.
There was a problem hiding this comment.
Strict types is a bad idea, you have a perfect example of why.
It provides no additional type-guarantee.
On the contrary, type declarations on signature boundaries do provide additional guarantee and thus prevent bugs.
Good news, we're adding them all in v5 when technically possible :)
There was a problem hiding this comment.
See #32828 as alternative.
There was a problem hiding this comment.
@nicolas-grekas , you mean 1? :)
@xabbuh, so, do you agree that we should close this?
There was a problem hiding this comment.
I mean that this situation will happen to all places where we added the string type - not only on forms.
There was a problem hiding this comment.
I would have only done that in places where we explicitly declared support for other data types before. But I also understand the argument about everyone having to do the type cast then (though I wouldn't expect that many people actually use integers as form names).
There was a problem hiding this comment.
@nicolas-grekas , yes, I got it. Should we add a note in the BC promise about that then?
There was a problem hiding this comment.
Sure, I meant 1. :)
The BC promise is only about minor versions, so that's a bit off topic, but I don't have a better proposal.
PR welcome on the BC promise then, to be clear we don't promise not hard-breaking strict types.
|
Closing in favor of #32828 |
This PR was merged into the 3.4 branch. Discussion ---------- [Form] update type of form $name arguments | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #32821 | License | MIT | Doc PR | - An alternative to #32821: where a string is expected, passing an int is fine, per PHP casting rules. Commits ------- 6d4dcad [Form] update type of form $name arguments
This PR deprecates passing ints to form building methods to ease upgrade to 5.0.
ping @nicolas-grekas , @xabbuh