Re: [PHP-DEV] NULL Coercion Consistency

On Fri, May 27, 2022 at 9:36 PM Craig Francis wrote: > I know I keep going on about this very simply example, but it represents a > fairly typical style of programming PHP, and I just do not understand what > the problem with it is: > > ``` > $search = $request->input('q'); // Laravel, returns

Re: [PHP-DEV] NULL Coercion Consistency

On 28 May 2022, at 07:25, Aleksander Machniak wrote: > > On 28.05.2022 04:36, Craig Francis wrote: >> On 8 Apr 2022, at 18:34, Craig Francis wrote: >>> I've written a new draft RFC to address the NULL coercion problems: >>> https://wiki.php.net/rfc/null_coercion_consistency >> I give up. > >

Re: [PHP-DEV] NULL Coercion Consistency

On 27 May 2022, at 10:11, Rowan Tommins wrote: > On 26/05/2022 13:20, Craig Francis wrote: >> First, the Docblock originally said this function did not accept NULL, but >> at runtime it accepted/coerced NULL to an empty string. This is exactly how >> `htmlspecialchars()` worked pre 8.1. Where

Re: [PHP-DEV] NULL Coercion Consistency

On 27 May 2022, at 07:44, Jordan LeDoux wrote: > On Thu, May 26, 2022 at 5:21 AM Craig Francis > wrote: >> It sounds like you got lucky - you have a function that has a problem with >> NULL (but I assume it's fine with an empty string?), and during your testing >> you happened to pass NULL to

Re: [PHP-DEV] NULL Coercion Consistency

On 26 May 2022, at 20:06, Michael Babker wrote: > On Thursday, May 26, 2022 at 11:41 AM, Craig Francis > mailto:cr...@craigfrancis.co.uk)> wrote: >> [...] If there is a good reason for throwing an exception when NULL is >> passed to `htmlspecialchars()`, then that reason would also apply to

Re: [PHP-DEV] NULL Coercion Consistency

On 26/05/2022 13:20, Craig Francis wrote: First, the Docblock originally said this function did not accept NULL, but at runtime it accepted/coerced NULL to an empty string. This is exactly how `htmlspecialchars()` worked pre 8.1. Where developers using static analysis tools can choose to

Re: [PHP-DEV] NULL Coercion Consistency

On Thu, May 26, 2022 at 5:21 AM Craig Francis wrote: > > It sounds like you got lucky - you have a function that has a problem with > NULL (but I assume it's fine with an empty string?), and during your > testing you happened to pass NULL to this function. As noted before, static > analysis is

Re: [PHP-DEV] NULL Coercion Consistency

On Thursday, May 26, 2022 at 11:41 AM, Craig Francis mailto:cr...@craigfrancis.co.uk)> wrote: > On 26 May 2022, at 15:01, Michael Babker wrote: > > On Thu, May 26, 2022 at 7:21 AM Craig Francis > > wrote: > > > That said, I would still like to know about the benefits of rejecting > > > NULL

Re: [PHP-DEV] NULL Coercion Consistency

On 26 May 2022, at 15:01, Michael Babker wrote: > On Thu, May 26, 2022 at 7:21 AM Craig Francis > wrote: >> That said, I would still like to know about the benefits of rejecting NULL >> for `htmlspecialchars()`, in the context of that Laravel Blade patch; >> because, if it is beneficial (vs

Re: [PHP-DEV] NULL Coercion Consistency

On Thu, May 26, 2022 at 7:21 AM Craig Francis wrote: > That said, I would still like to know about the benefits of rejecting NULL > for `htmlspecialchars()`, in the context of that Laravel Blade patch; > because, if it is beneficial (vs the BC break), they should revert that > patch... shouldn't

Re: [PHP-DEV] NULL Coercion Consistency

On 24 May 2022, at 09:47, Rowan Tommins wrote: > On 23/05/2022 19:45, Craig Francis wrote: > >> For those against my RFC, can you take a quick look at this patch for >> Laravel: >> >>

Re: [PHP-DEV] NULL Coercion Consistency

Hi, I can't refrain from replying again... On Sat, May 7, 2022 at 1:30 PM Mel Dafert wrote: > > It is exactly user-defined functions that this RFC introduces breakage for. > The behaviour to throw on null in user-defined functions exists since PHP > 7.0, and is being relied on. Changing these

Re: [PHP-DEV] NULL Coercion Consistency

On 8 May 2022, at 12:38, Mark Randall wrote: > On 08/05/2022 11:48, Jordan LeDoux wrote: >> This is not the case with null. If you use the unset() function on a >> variable for example, it will var_dump as null *and* it will pass an >> is_null() check *and* it will pass a $var === null *and* it

Re: [PHP-DEV] NULL Coercion Consistency

On 7 May 2022, at 22:11, Jordan LeDoux wrote: > On Sat, May 7, 2022 at 1:38 AM Craig Francis > wrote: > > Not what I'm going for... but anyway, to get an idea of your position, do you > think the string '15' should be coerced to a number, or should it fatal

Re: [PHP-DEV] NULL Coercion Consistency

On 09/05/2022 10:06, Robert Landers wrote: If you are writing library code, it is 8.1 compatible to avoid people opening issues about spamming their logs. Yes, I understand that such complaints are common, but we should be working to provide documentation and tooling to those users, rather

Re: [PHP-DEV] NULL Coercion Consistency

On 7 May 2022, at 18:16, Aleksander Machniak wrote: > On 07.05.2022 13:29, Mel Dafert wrote: >> It is exactly user-defined functions that this RFC introduces breakage for. >> The behaviour to throw on null in user-defined functions exists since PHP >> 7.0, and is being relied on. Changing these

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, May 9, 2022 at 10:18 AM Rowan Tommins wrote: > > On 08/05/2022 22:33, Björn Larsson via internals wrote: > > It's not only ugly code ;) To make your program/application/library 8.1 > > compatible using that codepattern requires en effort, but brings close > > to zero improvement, except

Re: [PHP-DEV] NULL Coercion Consistency

On 08/05/2022 22:33, Björn Larsson via internals wrote: It's not only ugly code ;) To make your program/application/library 8.1 compatible using that codepattern requires en effort, but brings close to zero improvement, except being 8.1 compatible. So the net effect is negative. Important

Re: [PHP-DEV] NULL Coercion Consistency

Den 2022-05-08 kl. 08:52, skrev Aleksander Machniak: On 07.05.2022 23:11, Jordan LeDoux wrote: What exactly would be the purpose of `?int` if this RFC was passed? To pass the value as null instead of 0? That's it? Yes. No change here. What about `int|float`? Which one would it be coerced

Re: [PHP-DEV] NULL Coercion Consistency

On 08/05/2022 11:48, Jordan LeDoux wrote: This is not the case with null. If you use the unset() function on a variable for example, it will var_dump as null *and* it will pass an is_null() check *and* it will pass a $var === null *and* it will return false for an isset() check. Null loses these

Re: [PHP-DEV] NULL Coercion Consistency

On Sat, May 7, 2022 at 11:53 PM Aleksander Machniak wrote: > > What happens if you pass FALSE to such an argument? int(0). The same > would happen with NULL. > > The thing that everyone seems to be glossing over with these coercion examples is that in order to have any scalar value, it must be

Re: [PHP-DEV] NULL Coercion Consistency

On 07.05.2022 23:11, Jordan LeDoux wrote: What exactly would be the purpose of `?int` if this RFC was passed? To pass the value as null instead of 0? That's it? Yes. No change here. What about `int|float`? Which one would it be coerced to? What happens if you pass FALSE to such an

Re: [PHP-DEV] NULL Coercion Consistency

On Sat, May 7, 2022 at 2:11 PM Jordan LeDoux wrote: > > I'm concerned from your replies in this thread and the content of the RFC > that you don't actually understand the extent of a BC-break you're > proposing. > > Sorry, that was a tad more combative than I intended. What I'm trying to say is

Re: [PHP-DEV] NULL Coercion Consistency

On Sat, May 7, 2022 at 1:38 AM Craig Francis wrote: > > Not what I'm going for... but anyway, to get an idea of your position, do > you think the string '15' should be coerced to a number, or should it fatal > error as well? e.g. > > $my_number = round($request->get('my_number')); > > '15' is

Re: [PHP-DEV] NULL Coercion Consistency

On 07.05.2022 13:29, Mel Dafert wrote: It is exactly user-defined functions that this RFC introduces breakage for. The behaviour to throw on null in user-defined functions exists since PHP 7.0, and is being relied on. Changing these now would introduce behaviour changes that are harder to find

Re: [PHP-DEV] NULL Coercion Consistency

On 7 May 2022 12:54:45 CEST, Craig Francis wrote: >I will note that my RFC does not change NULL coercion (why I quoted the >documentation), and I'm not against the other BC breaks where certain type >coercions are clearly problematic. > >It was 8.1 which introduced this specific BC problem

Re: [PHP-DEV] NULL Coercion Consistency

> On 7 May 2022, at 10:01, Marco Pivetta wrote: > > Hey Craig Hi Marco, Thanks for your thoughts. > On Sat, 7 May 2022, 10:39 Craig Francis, > wrote: > Not what I'm going for... but anyway, to get an idea of your position, do you > think the string '15'

Re: [PHP-DEV] NULL Coercion Consistency

Hey Craig On Sat, 7 May 2022, 10:39 Craig Francis, wrote: > Not what I'm going for... but anyway, to get an idea of your position, do > you think the string '15' should be coerced to a number, or should it fatal > error as well? e.g. > > $my_number = round($request->get('my_number')); >

Re: [PHP-DEV] NULL Coercion Consistency

On 7 May 2022, at 06:59, Aleksander Machniak wrote: > > On 08.04.2022 19:34, Craig Francis wrote: >> Hi, >> I've written a new draft RFC to address the NULL coercion problems: >> https://wiki.php.net/rfc/null_coercion_consistency > > As a voter, I'm in favor of this RFC. > > I suggest to

Re: [PHP-DEV] NULL Coercion Consistency

On 7 May 2022, at 04:45, Jordan LeDoux wrote: > > On Fri, Apr 8, 2022 at 10:35 AM Craig Francis > wrote: > https://wiki.php.net/rfc/null_coercion_consistency > > > > This RFC seems to be trying to force all

Re: [PHP-DEV] NULL Coercion Consistency

On 08.04.2022 19:34, Craig Francis wrote: Hi, I've written a new draft RFC to address the NULL coercion problems: https://wiki.php.net/rfc/null_coercion_consistency As a voter, I'm in favor of this RFC. I suggest to rename "Documentation" section title to "Scalars coercion inconsistency"

Re: [PHP-DEV] NULL Coercion Consistency

On Fri, Apr 8, 2022 at 10:35 AM Craig Francis wrote: > Hi, > > I've written a new draft RFC to address the NULL coercion problems: > > https://wiki.php.net/rfc/null_coercion_consistency > > This is due to the result of the Allow NULL quiz: > > https://quiz.craigfrancis.co.uk/ > > 14 votes for

Re: [PHP-DEV] NULL Coercion Consistency

On 3 May 2022, at 14:55, Rowan Tommins wrote: > > On 03/05/2022 12:37, Craig Francis wrote: >> But what is that benefit? I'm sorry, but I really don't see it. > > > I started drafting a longer reply, but honestly I don't think we're getting > anywhere. Every attempt to explain the benefit

Re: [PHP-DEV] NULL Coercion Consistency

On 03/05/2022 12:37, Craig Francis wrote: But what is that benefit? I'm sorry, but I really don't see it. I started drafting a longer reply, but honestly I don't think we're getting anywhere. Every attempt to explain the benefit seems to end in one of two ways: - an endless back and

Re: [PHP-DEV] NULL Coercion Consistency

> On 30 Apr 2022, at 18:05, Rowan Tommins wrote: > > On 27/04/2022 16:51, Craig Francis wrote: >> Forgive this primitive example, but this shows `$name` being used in three >> different ways, where an automated tool cannot simply change line 1 so it >> doesn't return a NULL, because it would

Re: [PHP-DEV] NULL Coercion Consistency

On 27/04/2022 16:51, Craig Francis wrote: Forgive this primitive example, but this shows `$name` being used in three different ways, where an automated tool cannot simply change line 1 so it doesn't return a NULL, because it would break the Register link. ``` $name = $request->get('name');

Re: [PHP-DEV] NULL Coercion Consistency

On 26 Apr 2022, at 21:11, Rowan Tommins wrote: > > On 26/04/2022 17:36, Guilliam Xavier wrote: >> function mt_rand(int $min = UNKNOWN, int $max = UNKNOWN): int {} >> >> documented with two signatures at >> https://www.php.net/manual/en/function.mt-rand.php >> >> mt_rand(): int >>

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, 25 Apr 2022 at 23:18, Larry Garfield wrote: > > > Internal functions error if you pass excessive arguments to a non-variadic > function. User-space functions just ignore the extras. This is an > inconsistency that has caused me considerable grief in the past year. > > I know Joe has

Re: [PHP-DEV] NULL Coercion Consistency

On 25 Apr 2022, at 22:07, Rowan Tommins wrote: > On 25/04/2022 10:33, Craig Francis wrote: > >>> The fact that internal functions have parameter parsing behaviour that is >>> almost impossible to implement in userland, and often not even consistent >>> between functions, is a wart of engine

Re: [PHP-DEV] NULL Coercion Consistency

On 26/04/2022 17:36, Guilliam Xavier wrote: function mt_rand(int $min = UNKNOWN, int $max = UNKNOWN): int {} documented with two signatures at https://www.php.net/manual/en/function.mt-rand.php mt_rand(): int mt_rand(int $min, int $max): int This is actually a really

Re: [PHP-DEV] NULL Coercion Consistency

On Tue, Apr 26, 2022 at 12:18 AM Larry Garfield wrote: > On Mon, Apr 25, 2022, at 4:07 PM, Rowan Tommins wrote: > > > Off the top of my head, I don't know what other inconsistencies remain, > > but my point was that in every case so far, internal functions have been > > adapted to match

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, Apr 25, 2022, at 4:07 PM, Rowan Tommins wrote: > Off the top of my head, I don't know what other inconsistencies remain, > but my point was that in every case so far, internal functions have been > adapted to match userland, not vice versa. Internal functions error if you pass

Re: [PHP-DEV] NULL Coercion Consistency

On 25/04/2022 10:33, Craig Francis wrote: The fact that internal functions have parameter parsing behaviour that is almost impossible to implement in userland, and often not even consistent between functions, is a wart of engine internals, not a design decision. Bit of a tangent, but do you

Re: [PHP-DEV] NULL Coercion Consistency

On 25 Apr 2022, at 11:35, Rowan Tommins wrote: > Taking time to find and make fixes is the whole point of deprecation notices > - if nothing else changes, they can expect to have another 3.5 years before a > version of PHP is released where these become errors. Upgrading to PHP 8.1 as > soon

Re: [PHP-DEV] NULL Coercion Consistency

On 25/04/2022 10:44, Craig Francis wrote: You're right, I am working with a few development teams that are simply not upgrading to 8.1 at the moment, they don't have the time to fix this issue... two are using set_error_handler() to ignore this specific deprecation notice, and one team has

Re: [PHP-DEV] NULL Coercion Consistency

> On 21 Apr 2022, at 17:32, Andreas Leathley wrote: > >>> There is another 3.5 years until PHP 9 is likely to come out, which is a >>> lot of time for people to adjust their codebase. I could even see an >>> argument for not promoting it to a fatal error in 9.0 if so many people >>> need

Re: [PHP-DEV] NULL Coercion Consistency

On 21 Apr 2022, at 15:09, Rowan Tommins wrote: > On Wed, 20 Apr 2022 at 18:02, Craig Francis wrote: >> I'm just trying to focus on how PHP has worked > > You keep repeating this mantra, but user-defined functions with declared > parameter types have never accepted nulls, in any mode, unless

Re: [PHP-DEV] NULL Coercion Consistency

On 21 April 2022 15:40:42 BST, Christian Schneider wrote: >You are leaving out option 3 (which is not part of the RFC but should still be >on the table IMHO): >3) Leave the behavior but change the parameter definition to nullable to match >the implementation. Those weren't options, they were

Re: [PHP-DEV] NULL Coercion Consistency

There is another 3.5 years until PHP 9 is likely to come out, which is a lot of time for people to adjust their codebase. I could even see an argument for not promoting it to a fatal error in 9.0 if so many people need more time. If it's deprecated, that is an intent to break... and if no

Re: [PHP-DEV] NULL Coercion Consistency

Am 21.04.2022 um 16:09 schrieb Rowan Tommins : > All of that, and the "consistency" in the title of your RFC, is a complete > distraction from the real questions: > > 1) given a null input, and a non-nullable parameter, what should the > run-time do? > 2) what is the best way to help users update

Re: [PHP-DEV] NULL Coercion Consistency

On Wed, 20 Apr 2022 at 18:02, Craig Francis wrote: > I'm just trying to focus on how PHP has worked You keep repeating this mantra, but user-defined functions with declared parameter types have never accepted nulls, in any mode, unless explicitly marked with "?" or "= null". The fact that

Re: [PHP-DEV] NULL Coercion Consistency

On Wed, 20 Apr 2022 at 20:02, Andreas Leathley wrote: > I don't get why you would add strval everywhere. Why are you getting null > everywhere? As to adding `strval($var)`, or `(string) $var`, or `$var ?? ""` everywhere... that's because we (or frameworks) cannot simply change the defaults

Re: [PHP-DEV] NULL Coercion Consistency

On 14.04.22 14:14, Craig Francis wrote: Yep, I agree with everything you have said there, and it's what George seems to be working towards (which I also agree with): https://github.com/Girgias/unify-typing-modes-rfc Yet your RFC goes exactly against the quoted document by making the

Re: [PHP-DEV] NULL Coercion Consistency

On Wed, 20 Apr 2022 at 18:26, Christoph M. Becker wrote: > Null is *not* a scalar type[1], though. This is the reason why it is > not coerced for userland functions using *scalar* type hints with > coercive typing. > > [1] > But why not? and how many developers

Re: [PHP-DEV] NULL Coercion Consistency

On 20.04.2022 at 19:02, Craig Francis wrote: > In contrast, failing early at runtime, on something that is not actually a > problem, like the examples in my RFC, creates 2 problems (primarily > upgrading; but also adding unnecessary code to explicitly cast those > possible NULL values to the

Re: [PHP-DEV] NULL Coercion Consistency

On Tue, 19 Apr 2022 at 14:17, Rowan Tommins wrote: > On 19/04/2022 12:34, Craig Francis wrote: > > The developers I work with would assume the last definition > > > I think you've somewhat missed my point. I wasn't talking about people's > habits or preferences, I was talking about different

Re: [PHP-DEV] NULL Coercion Consistency

On 19/04/2022 12:34, Craig Francis wrote: The developers I work with would assume the last definition I think you've somewhat missed my point. I wasn't talking about people's habits or preferences, I was talking about different *scenarios* where null is used to mean different things. Yes,

Re: [PHP-DEV] NULL Coercion Consistency

On Sat, 16 Apr 2022 at 12:17, Rowan Tommins wrote: > On 8 April 2022 18:34:52 BST, Craig Francis > wrote: > >I've written a new draft RFC to address the NULL coercion problems: > > > >https://wiki.php.net/rfc/null_coercion_consistency > > > I'm sympathetic to the general problem you're trying

Re: [PHP-DEV] NULL Coercion Consistency

On 8 April 2022 18:34:52 BST, Craig Francis wrote: >I've written a new draft RFC to address the NULL coercion problems: > >https://wiki.php.net/rfc/null_coercion_consistency I'm sympathetic to the general problem you're trying to solve, but I'm not convinced by the argument that this is about

Re: [PHP-DEV] NULL Coercion Consistency

On Thu, 14 Apr 2022 at 10:01, Andreas Leathley wrote: > I have never used strict_types in any code I have ever written, and I care > about types and type coercions. Yet I do not like the strict_types > distinction and I am glad that I do not need to use it, and I think we are > not that far away

Re: [PHP-DEV] NULL Coercion Consistency

On 14.04.22 10:10, Craig Francis wrote: My intro says "Roughly 85% scripts do not use strict_types=1", and "Roughly 33% of developers use static analysis" (source of numbers noted in my RFC)... while that does not guarantee anything, it's a fairly good indication that most developers do not

Re: [PHP-DEV] NULL Coercion Consistency

On Thu, 14 Apr 2022 at 08:31, Robert Landers wrote: > > I see null as a real type > > This confuses me... Andreas is probably the best person to explain their view; oddly I see NULL as it's own type as well, because are there are times where it's useful to determine the difference between

Re: [PHP-DEV] NULL Coercion Consistency

On Wed, 13 Apr 2022 at 20:08, Andreas Leathley wrote: > Mentioning the documentation as a reason to be "consistent" (which comes > up again and again in your arguments with this RFC) just seems like a > bogus reason to me. It is nitpicking about specific sentences in the > documentation without

Re: [PHP-DEV] NULL Coercion Consistency

On Wed, Apr 13, 2022 at 9:45 PM Craig Francis wrote: > > https://wiki.php.net/rfc/null_coercion_consistency > > On Wed, 13 Apr 2022 at 15:15, G. P. B. wrote: > > > I've spent a large amount of time making coercive typing mode more > > sensible and aligning the behaviour as close to reasonably

Re: [PHP-DEV] NULL Coercion Consistency

https://wiki.php.net/rfc/null_coercion_consistency On Wed, 13 Apr 2022 at 15:15, G. P. B. wrote: > I've spent a large amount of time making coercive typing mode more > sensible and aligning the behaviour as close to reasonably possible with > strict_types so that the possibility of dropping

Re: [PHP-DEV] NULL Coercion Consistency

On 13.04.22 15:36, Craig Francis wrote: On Mon, 11 Apr 2022 at 20:08, Andreas Leathley wrote: You are taking parts of the documentation out of context, and omitting the start of the whole "Converting to string" section: "A value can be converted to a string using the (string) cast

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, 11 Apr 2022 at 19:22, Craig Francis wrote: > On Mon, 11 Apr 2022 at 16:14, G. P. B. wrote: > >> But the implementation caused a Type Error when coercing NULL for >>> everyone (even when not using *strict_types=1*), this seems more of an >>> over-sight >>> >> is utterly wrong and was a

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, 11 Apr 2022 at 19:57, Mark Baker wrote: > This doesn't only apply to end user developers, but also to library and > toolchain developers who need to maintain code covering a range of PHP > versions > Yep, and thank you for commenting. Library authors are the ones receiving pressure at

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, 11 Apr 2022 at 20:08, Andreas Leathley wrote: > You are taking parts of the documentation out of context, and omitting > the start of the whole "Converting to string" section: > > "A value can be converted to a string using the (string) cast or the > strval() function. String conversion

Re: [PHP-DEV] NULL Coercion Consistency

On 11.04.22 20:22, Craig Francis wrote: Just take NULL to String coercion as an example, the documentation clearly and simply says “null is always converted to an empty string”, this needs to be updated to end with "... except when being passed to a function, in which case NULL will result in a

Re: [PHP-DEV] NULL Coercion Consistency

On 11/04/2022 20:22, Craig Francis wrote: Keep in mind, if you're using `strict_types=1`, great, you're not affected (I'm not either)... however, I work with quite a few developers, and it's causing them a lot of problems, and their current approach is to either disable the deprecation warnings,

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, 11 Apr 2022 at 16:14, G. P. B. wrote: > But the implementation caused a Type Error when coercing NULL for everyone >> (even when not using *strict_types=1*), this seems more of an over-sight >> > is utterly wrong and was a conscious design choice based on the widely > accepted view that

Re: [PHP-DEV] NULL Coercion Consistency

On Fri, 8 Apr 2022 at 18:35, Craig Francis wrote: > Hi, > > I've written a new draft RFC to address the NULL coercion problems: > > https://wiki.php.net/rfc/null_coercion_consistency The statement that: > But the implementation caused a Type Error when coercing NULL for everyone > (even when

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, 11 Apr 2022 at 13:05, Guilliam Xavier wrote: > > https://wiki.php.net/rfc/null_coercion_consistency > > You've updated the **Documentation** section (also: did you mean > "inconsistency" rather than "inconstancy"?) but still not the **Proposal** > (BTW all those sections between

Re: [PHP-DEV] NULL Coercion Consistency

Hi, > https://wiki.php.net/rfc/null_coercion_consistency Thanks for the draft. On Sat, Apr 9, 2022 at 11:30 AM Craig Francis wrote: > On Fri, 8 Apr 2022 at 19:07, Craig Francis > wrote: > > > On Fri, 8 Apr 2022 at 18:54, Mel Dafert wrote: > > > >> In particular, does this propose changing

Re: [PHP-DEV] NULL Coercion Consistency

On Fri, 8 Apr 2022 at 19:07, Craig Francis wrote: > On Fri, 8 Apr 2022 at 18:54, Mel Dafert wrote: > >> In particular, does this propose changing user-defined functions under >> strict_types=0 to accept null for scalar types? >> > > With user defined functions, I think it's up for debate (still

Re: [PHP-DEV] NULL Coercion Consistency

On Fri, 8 Apr 2022 at 18:54, Mel Dafert wrote: > In particular, does this propose changing user-defined functions under > strict_types=0 to accept null for scalar types? > > Eg., this will be allowed (under strict_types=0): > ``` > function x(string $y, int $z) { > ... > } > x(null, null);

Re: [PHP-DEV] NULL Coercion Consistency

On 8 April 2022 19:34:52 CEST, Craig Francis wrote: >Hi, > >I've written a new draft RFC to address the NULL coercion problems: > >https://wiki.php.net/rfc/null_coercion_consistency > >This is due to the result of the Allow NULL quiz: > >https://quiz.craigfrancis.co.uk/ > >14 votes for Fatal Type

[PHP-DEV] NULL Coercion Consistency

Hi, I've written a new draft RFC to address the NULL coercion problems: https://wiki.php.net/rfc/null_coercion_consistency This is due to the result of the Allow NULL quiz: https://quiz.craigfrancis.co.uk/ 14 votes for Fatal Type Errors irrespective of `strict_types=1`; 13 votes for NULL