Bug #81177 [Com]: Typehint parameter is ignored when passing NULL directly. Is it correct?

From: Date: Sat, 19 Jun 2021 20:55:34 +0000
Subject: Bug #81177 [Com]: Typehint parameter is ignored when passing NULL directly. Is it correct?
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-234515@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=81177&edit=1 ID: 81177 Comment by: a at b dot c Reported by: 6562680 at gmail dot com Summary: Typehint parameter is ignored when passing NULL directly. Is it correct? Status: Not a bug Type: Bug Package: *General Issues Operating System: Win10 PHP Version: Irrelevant Block user comment: N Private report: N New Comment: Pull requests are welcome. Previous Comments: ------------------------------------------------------------------------ [2021-06-19 20:38:57] 6562680 at gmail dot com Last 5 years you solving problems with a words. Even then once i say "would be great to use starts()" function and after 2 years FINALLY you decide to create it... and even then it returns false creates one more if. Speaking speaking speaking explaining explaining... In that time we've got PHP8 with union types without array types, still havent generics, still havent nested classes and readonly properties, havent internal dependency injector, havent that damn decorators... But well, we have something "CurlHandle" that interfaced resource handler, some ArrayPrototypiers and you have discussion to multiline call syntax " attr > call > call > call " that expected only in SCRIPTS deployed on microservices without OOP and patterns... Continue speaking. Time is on other side ------------------------------------------------------------------------ [2021-06-19 20:18:53] requinix@php.net https://www.php.net/manual/en/functions.arguments.php#functions.arguments.default Every variable must have a value. Attempting to use a variable that does not have a value (because it hasn't been created yet) will "return" null, but that in no way means a null value represents undefined. Specifying =null as the optional value for a parameter necessarily means that the parameter supports it, therefore calling the function with null as an explicit value is not prohibited. ------------------------------------------------------------------------ [2021-06-19 19:54:56] 6562680 at gmail dot com My problem? No, seems it's like PHP problem, about we don't want the "undefined" type (i agree with) Need some way in typehint that means "default value" if null passed or constant like infinity "UNDEFINED" that pass from parent function to child... not sure it will solve. Currently we can do like "section 2" but when phpstorm autocompletes arguments - we wont see default values. In my project its not a problem. When you prefer vendor libraries - its mandatory. In short - typehint suggestions: 1. way to mark php null as undefined 2. way to detect empty string in type hint Would like anybody finally suggests AGAIN class nesting and readonly properties and that request wont be ignored AGAIN. But its another story... ------------------------------------------------------------------------ [2021-06-19 18:54:36] rtrtrtrtrt at dfdfdfdf dot dfd > 1) If use just "$a" - it will fail is i didnt pass the argument correct - it isn't an optional param > 2) If use "int $a" - it will fail if argument is not an integer correct > 3) If use "$a = 123" - if wont fail and if i DIDNT PASS > argument - it will be 123, but i still can pass NULL what else? it's an optional, NON-TYPED param so WHAT is your problem? ------------------------------------------------------------------------ [2021-06-19 18:51:55] 6562680 at gmail dot com There is one problem with "section 2" way - PHPStorm wont highlight the function has "default value" ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=81177 -- Edit this bug report at https://bugs.php.net/bug.php?id=81177&edit=1

« previous php.bugs (#234515) next »