Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116988 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28756 invoked from network); 7 Feb 2022 07:20:16 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 7 Feb 2022 07:20:16 -0000 To: internals@lists.php.net Date: Mon, 7 Feb 2022 08:35:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 87.81.129.66 Subject: Re: [PHP-DEV] Allowing NULL for some internal functions From: marandall@php.net (Mark Randall) Message-ID: On 07/02/2022 01:27, Craig Francis wrote: > I know one person simply said this was a "terribl > idea", but I'm still > waiting to hear any details on why. The changes you propose are not something that I am comfortable with either. I understand your motivations in proposing them, but to my mind it goes against the direction that PHP is developing, which I think is the right one, where errors and likely errors result in stopping execution rather than allowing it continue, potentially silently (dependent on error handling settings). If a parameter expects a string, that is what it should be given, and its the callers' responsibility to ensure that is the case. If they fail to do so then it's an error just like any other. IMHO reverting to "If it's a null we'll just pretend its a string" is contrary to how the language should be progressing. It sucks that it was ever allowed in the first place. PHP has a long history of making descisions to try to make things 'just work', and if history teaches us anything, its that we inevitably come to regret these descisions down the line. Mark Randall