Re: [PHP-DEV] Allowing NULL for some internal functions

Den 2022-01-02 kl. 00:17, skrev Craig Francis: On Thu, 2 Dec 2021 at 15:19, Sara Golemon wrote: On Thu, Dec 2, 2021 at 8:48 AM Craig Francis wrote: Is there any value in me proposing an RFC to update *some* internal functions so they can accept NULL? I'm not hard against this idea. The

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, 7 Feb 2022 at 18:39, Larry Garfield wrote: > 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" t

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, Feb 7, 2022, at 10:39 AM, Craig Francis wrote: > On Mon, 7 Feb 2022 at 15:15, Larry Garfield 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 a

Re: [PHP-DEV] Allowing NULL for some internal functions

On 07/02/2022 15:34, Craig Francis wrote: So are you suggesting that all the frameworks should change their default to an empty string? or every single project should update every use of these input functions to always override this default, or cast the received value to always be a string? all t

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

Hi Dan On 2/7/22 17:36, Dan Ackroyd wrote: So basically all the other languages I researched do not provide arguments within back traces. Uh, that kind of suggests that providing arguments at all is a mistake, and that removing could be the way to go. I mean other than everyone complaining abo

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, 7 Feb 2022 at 15:15, Larry Garfield wrote: > The goal is consistency, so keep it consistent. I'd be happy with that. The only reason I've taken this approach is for developers using type checking to identify certain mistakes in their code (which can be useful); so I wanted to keep th

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

On Tue, 11 Jan 2022 at 09:11, Tim Düsterhus, WoltLab GmbH wrote: > > So basically all the other languages I researched do not provide > arguments within back traces. Uh, that kind of suggests that providing arguments at all is a mistake, and that removing could be the way to go. I mean other than

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, 7 Feb 2022 at 12:34, Mark Randall wrote: > With regards to your framework comment, any framework worth its salt > will also have the option to provide a default value other than null > when the value is not provided. > Frameworks do allow developers to provide their own default value wh

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, Feb 7, 2022, at 6:57 AM, Christian Schneider wrote: > Am 07.02.2022 um 13:07 schrieb G. P. B. : > So you are basically saying that we should discuss making it > strlen(?string $string): int > which would be cleaner, I agree. I would agree here as well. The goal is consistency, so k

Re: [PHP-DEV] Allowing NULL for some internal functions

Am 07.02.2022 um 13:07 schrieb G. P. B. : > On Mon, 7 Feb 2022 at 09:34, Christian Schneider > wrote: > > 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

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, 7 Feb 2022 at 12:07, G. P. B. wrote: > The list of proposed functions is also excessive and just feels that any > function which raised a diagnostic during a test run on 8.1 was chugged > into it. > Not really, while I did create a throw-away script that used `get_defined_functions()` a

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

Hi Internals! On 1/31/22 10:54, Tim Düsterhus, WoltLab GmbH wrote: I plan to open voting on Wednesday, February, 2nd. Voting will run 2 weeks, 2/3 majority with the concept being voted on as explained in the "Proposed Voting Choice" section: https://wiki.php.net/rfc/redact_parameters_in_back_tra

Re: [PHP-DEV] Allowing NULL for some internal functions

On 07/02/2022 12:05, Craig Francis wrote: And specifically with NULL, strings in C are a "one-dimensional array of characters terminated by a null character", so you could say that NULL is very similar to an empty string - maybe that helps address the "pretend its a string" objection? In this

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, 7 Feb 2022 at 09:34, Christian Schneider wrote: > > 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. > > The decision to define e.g. strlen()

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, 7 Feb 2022 at 08:36, Mark Randall wrote: > 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 contin

Re: [PHP-DEV] Allowing NULL for some internal functions

Am 07.02.2022 um 09:35 schrieb Mark Randall : > 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. > > I understand your motivations in proposing them, but to my mind it goes > against the di

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, Feb 7, 2022 at 9:35 AM Mark Randall wrote: > 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. >

Re: [PHP-DEV] Allowing NULL for some internal functions

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