On Mon, Feb 7, 2022, at 10:39 AM, Craig Francis wrote: > On Mon, 7 Feb 2022 at 15:15, Larry Garfield <la...@garfieldtech.com> wrote:
> If there's an argument to be made to rewiden a type to include null, make >> that case and have that debate on a function by function basis. > > > I'm fine with that, but I worry people are underestimating the size of the > problem (having a debate on each one would take a long time). > > I've put together my proposed list, it took a few days, and a lot of > thought: > > https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-change.md I'm not suggesting a separate RFC for each. One RFC with several votes in it is fine, IMO. What I disagree with is changing the definition of strict_types=0 from "use the well-documented coercion logic at parameter and return points" to "use the well-documented parameter and return points, and also add implicit nullability but only for internal functions, sometimes". If it makes sense for strlen() to be nullable, then it makes sense for strlen() to be nullable. One or the other, not both based on a flag. > I've asked for suggestions and pull requests a few times, and the best I've > got is `$path`/`$domain` for `setcookie()` (I disagree because `NULL` is > often used for those arguments, so that `$secure` and `$httponly` can be > set to true). Such is the RFC process... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
