-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Fix various bool-type coercions #61103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment has been minimized.
This comment has been minimized.
@@ -85,7 +85,7 @@ protected function processValue(mixed $value, bool $isRoot = false): mixed | |||
$setters = $value->getMethodCalls(); | |||
$value->setMethodCalls($withers); | |||
foreach ($setters as $call) { | |||
$value->addMethodCall($call[0], $call[1], $call[2] ?? false); | |||
$value->addMethodCall($call[0], $call[1], isset($call[2]) && $call[2]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not change that, as we expect the third array value to be a boolean. Instead, we should fix the invalid usages of the method calls.
85f4d6a
to
b3d30e3
Compare
Thank you @Girgias. |
@@ -128,7 +128,7 @@ public function disableMagicSet(): static | |||
*/ | |||
public function isMagicCallEnabled(): bool | |||
{ | |||
return (bool) ($this->magicMethods & PropertyAccessor::MAGIC_CALL); | |||
return $this->magicMethods & PropertyAccessor::MAGIC_CALL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isnt this producing an integer now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see the return type, which cannot be bypassed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The return type will create an implicit cast to bool, which is precisely what @Girgias tries to deprecated in PHP 8.5 AFAICT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct, but this is not done yet :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i dont understand it, why would you want to rely on not using strict_types=1
currently? also, why opening up a deprecation, if the future fix is adding back (bool)
again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strict types was a bad idea that makes writing PHP more fragile, see https://github.com/Girgias/unify-typing-modes-rfc?tab=readme-ov-file#unintended-consequences-of-strict_types-mode
You might not agree but that's nonetheless the way Symfony does types.
The future is not adding back the cast. At least not before any vote happened on the topic.
So this change is just bringing consistency with the current policies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, i understand the POV a bit better now.
that said
Use of explicit casts to conform to type requirements
im fine with explicitness :) i mean, psalm complains about it 😅
This is cherry-picking some of the commits from #60890 which are basically bugs.
Not sure what the commit naming policy is so do let me know if you want me to manually rebase and rename commits following some guidelines.