Re: [PHP-DEV] Array functions with strict comparison

On 14 Nov 2023, at 17:49, Robert Landers wrote: > One of the most beautiful things about PHP is that null == 0 == false, or '5' > == 5 == 5.0, or 1 == true == 'hello world', which is so incredibly handy in > web-dev that to ignore it is inviting bugs. Headers may or may not be set, > form

Re: [PHP-DEV] Passing null to parameter

> On 10 Nov 2023, at 20:00, Rowan Tommins wrote: > [...] Wherever it is used, "null" is a confusing and often controversial > concept. In different contexts, it is used for different things, and has > different ideal behaviours. It's a whole debate on its own, and bringing in > other types of

Re: [PHP-DEV] Passing null to parameter

On 10 Nov 2023, at 12:16, Andreas Leathley wrote: > Also note that in your example $q could be an array (leading to a fatal error > in the code)from the request data, which is why checking types thoroughly > (not just coercing them with strval) can be helpful in avoiding unexpected >

Re: [PHP-DEV] Passing null to parameter

On 10 Nov 2023, at 11:47, Alex Wells wrote: > It fails to correctly change the type of the variable to nullable due to the > coalescing operator. This is a bug in PHPStan, Cool, and Kamil notes that bleeding edge has fixed this, that's good... but how many developers do you think are using

Re: [PHP-DEV] Passing null to parameter

On 10 Nov 2023, at 11:11, Kamil Tekiela wrote: >> That's what I thought, but for some reason, casting null is deprecated only >> when it's provided as an argument to functions, all other cases it's fine... >> weird right? > > > No, passing null to non-nullable parameters is already an error.

Re: [PHP-DEV] Passing null to parameter

On 10 Nov 2023, at 10:54, Alex Wells wrote: > PHPStan does find them: > https://phpstan.org/r/38fc1545-2567-49b9-9937-f275dcfff6f5 It does not: https://phpstan.org/r/c533ff42-80e4-4309-9751-1ec79e359946

Re: [PHP-DEV] Passing null to parameter

First, thanks Rowan (same to you Kamil), I do appreciate your thoughts on this... On 9 Nov 2023, at 20:01, Rowan Tommins wrote: > On 09/11/2023 14:58, Craig Francis wrote: >> We might as well make the PHP 9 upgrade as hard as possible, just to force a >> little bit of

Re: [PHP-DEV] Passing null to parameter

On 9 Nov 2023, at 16:08, Kamil Tekiela wrote: > Automatic casting of null to other types is a handy feature and deprecating > it brings no benefit to anyone. That's what I thought, but for some reason, casting null is deprecated only when it's provided as an argument to functions, all other

[PHP-DEV] Re: Passing null to parameter

On 29 Oct 2023, at 11:02, Craig Francis wrote: > I'm getting really annoyed at the "Passing null to parameter" problem, As I'm getting the usual negative response (-3), should I write an RFC to deprecate NULL coercion in all contexts? At the moment it's weird that `print($nul

Re: [PHP-DEV] Passing null to parameter

On 29 Oct 2023, at 11:14, Kamil Tekiela wrote: > A code like this already throws a fatal error. > > function enc(string $a){} > enc(null); > > The only thing remaining to be fixed in PHP 9 is to make this error > consistent on all function invocations. Or, be consistent with all of the

[PHP-DEV] Passing null to parameter

Hi Internals, I'm getting really annoyed at the "Passing null to parameter" problem, and it happens with new code as well. I know you have distain for websites that don't use strict types, or static analysis at the strictest level, but yesterday I was working on a 15 year old website, it still

Re: [PHP-DEV] Custom object equality

On 18 Oct 2023, at 13:50, someniatko wrote: > There were already suggestions on the mailing list to allow "overloading" > existing `==` operator, and some suggestions went even as far as overloading > `<`, `>=` etc operators. Slightly off-topic, but concatenation? Just as a possible

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On 12 Oct 2023, at 19:50, Jordan LeDoux wrote: > That's not how voting works in the PHP project. The 2/3 is for whether or not > the feature change should be made at all. In the case that there are multiple > implementations or variations, the choice between those is usually simple > majority.

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On 25 Sep 2023, at 18:07, Tim Düsterhus wrote: > I've now did the maths and you really need rate limiting no matter if you use > costs 10, 11 or 12, so I believe the DoS argument is a little moot. Yes, someone being malicious could easily generate enough requests to create an Denial of

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On 22 Sep 2023, at 08:04, Nicolas Grekas wrote: > For the record, I voted for 11 because I think it's nicer to end users (I > guess many don't know they could have a potential DoS vector via password > submissions), and also because it's going to be easy to raise again in > 8.5/9.0. +1 I

Re: [PHP-DEV] RFC: Increasing the default BCrypt cost

On 7 Sep 2023, at 18:26, Tim Düsterhus wrote: > in response to the recent "PASSWORD_DEFAULT value" thread [1], I've created > an RFC to discuss an increase of the default BCrypt costs for > `password_hash()` from the current value of 10. > > https://wiki.php.net/rfc/bcrypt_cost_2023 Thanks

Re: [PHP-DEV] pipes, scalar objects and on?

On 18 Jul 2023, at 16:13, Larry Garfield wrote: > PHP at the moment leans heavily on the "null is error and build tooling > around that" approach Yep, you should never use NULL in your code, the following is catastrophically bad... $search = ($_GET['q'] ?? NULL); $search =

Re: [PHP-DEV] Future stability of PHP?

On 9 Apr 2023, at 23:10, Kamil Tekiela wrote: > I wonder about this every time I hear this claim. What exactly changed in PHP > 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a > little more difficult because of some of the recent deprecations, but that's > still

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

On 18 Jan 2023, at 12:22, G. P. B. wrote: > [...] > I appreciate being shown concrete cases about the useful ness of this > operation. > The reason I didn't go with adding support for decrementing alphanumeric > strings is that it was unanimously rejected. > However, if Rowan's suggestion of

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

On 17 Jan 2023, at 14:28, G. P. B. wrote: > https://wiki.php.net/rfc/saner-inc-dec-operators > > The goal of this RFC is to reduce language complexity by making $v++ behave > like $v += 1 and $v-- behave like $v -= 1; > > I am expecting the contentious part of the proposal to be the deprecation

Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index

On 13 Dec 2022, at 15:45, Rowan Tommins wrote: > Although presumably they return null rather than an empty string precisely so > that users can check if the value was provided, without providing an extra > method equivalent to isset($_GET['q']), e.g. > > [...] > > For cases where you don't

Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index

On 13 Dec 2022, at 12:39, Rowan Tommins wrote: > On 13/12/2022 10:11, Craig Francis wrote: >> The null value can come from many sources (e.g. GET/POST/COOKIE/databases) > > > These two examples are interesting in conjunction: $_GET, $_POST, and > $_COOKIE will never conta

Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index

On 12 Dec 2022, at 23:36, Thomas Hruska wrote: > I suspect many people are in a similar holding pattern who are currently > running packaged 7.4.x and are just now discovering all of the changes for > PHP 8.x as they are planning out their system upgrade paths in the coming > months. While

Re: [PHP-DEV] Microseconds to error log

On Fri, 25 Nov 2022 at 14:01, Mikhail Galanin < mikhail.gala...@team.bumble.com> wrote: > 2. The INI-thing. When initially I mentioned being configurable, I > realised that it could've been perceived in many different ways: > > - we can enable/disable the microseconds > - we can choose from a

Re: [PHP-DEV] Microseconds to error log

On Mon, 31 Oct 2022 at 18:23, Rowan Tommins wrote: > I guess we could have the setting be "use new date format", and control > both the precision and whether the format is ISO 8601 compliant, but I'm > not convinced of the value > Thanks, and that's fair to avoid complicating the error

Re: [PHP-DEV] Microseconds to error log

On Sun, 30 Oct 2022 at 17:42, Rowan Tommins wrote: > In case of any confusion, I think this should be configurable as > "include microseconds: on / off", not configurable as "enter date format". > Any reason it can't be configured to use ISO 8601? Apache 2.4 allows you to use `LogFormat "...

[PHP-DEV] Re: NULL Coercion Consistency

On 28 May 2022, at 03: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. For everyone affect

Re: [PHP-DEV] Error behaviour for max_input_vars

On 14 Sep 2022, at 20:55, Tim Düsterhus wrote: > As indicated by the phrasing in my previous email, this knowledge does not > enable an attacker to do anything that they wouldn't be able to do otherwise. One possibility... when you say the attacker is able to "not send all the fields", would

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

On 22 Jun 2022, at 05:38, Pierrick Charron wrote: > Here is the RFC that reflects our current conversations. > > https://wiki.php.net/rfc/curl-url-api > > Feel free to give any feedback, concern or support :-) Thanks Pierrick, I think this is a good approach to add the URL functionality to

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

On 20 Jun 2022, at 14:44, Christoph M. Becker wrote: > On 20.06.2022 at 15:13, Pierrick Charron wrote: >> about the new Curl URL API, I think it's still time to finalize the >> discussions and include it in the 8.2 release as it allows us to solve some >> potential security issues. > > Given

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

On 17 Jun 2022, at 09:27, Lynn wrote: > ... That said, we should avoid having: cURL procedural + cURL procedural in > objects + cURL OOP. Having 2 different object based libraries to do the same > thing PHP is confusing and will just end up in way too many Stack Overflow > questions. > >

Re: [PHP-DEV] Adding new closing tag =?> for keeping trailing newline

On 7 Jun 2022, at 16:27, Robert Landers wrote: > > On Mon, Jun 6, 2022 at 6:47 PM shinji igarashi > wrote: >> >> Hello! >> >> I asked for opinions on reddit also. >> https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/ >> >> Popularity on reddit and

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_coe

[PHP-DEV] Re: NULL Coercion Consistency

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. I'm clearly not clever enough to understand what the benefits are for breaking NULL coercion... consi

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()`

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 >> y

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 re

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,

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: >> >> https://github.com/laravel/f

[PHP-DEV] Re: [Vote] MySQLi Execute Query

On 11 May 2022, at 15:55, Craig Francis wrote: > I've just opened the vote for MySQLi Execute Query, and I'm going to close it > on 2022-05-25. > > Discussion: https://externals.io/message/117486 > RFC: https://wiki.php.net/rfc/mysqli_execute_query Thank you everyone, The vot

[PHP-DEV] Re: [Vote] MySQLi Execute Query

On 11 May 2022, at 15:55, Craig Francis wrote: > I've just opened the vote for MySQLi Execute Query, and I'm going to close it > on 2022-05-25. > > Discussion: https://externals.io/message/117486 > <https://externals.io/message/117486> > RFC: https://wiki.php.net/

Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions

On 23 May 2022, at 19:58, Juliette Reinders Folmer wrote: > I also fear that for code bases which do not (yet) use scalar type > declarations, this will be one more argument not to introduce scalar type > declarations (while they should). > > I'd say that for this RFC to be acceptable it

[PHP-DEV] Re: NULL Coercion Consistency

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 > <https://wiki.php.net/rfc/null_coercion_consistency> For those against my RFC, can you take a quick loo

Re: [PHP-DEV] Early feedback on encrypted session PR

On 18 May 2022, at 18:43, Christoph M. Becker wrote: > On 18.05.2022 at 18:37, Craig Francis wrote: >> I would hope both are very rare, but I'm still writing up reports about >> developers doing things like `file_put_contents('/tmp/' . $_POST['id'], >> $_POST['message'])`,

Re: [PHP-DEV] Early feedback on encrypted session PR

On 18 May 2022, at 17:02, Mark Randall wrote: > Personally I usually just throw the session key through a one-way hash so the > original session ID never gets written to a backing store. Good idea, but that's not done by default. > I'm not sure why reversible encryption needs to take place?

Re: [PHP-DEV] Early feedback on encrypted session PR

On 17 May 2022, at 23:11, Mark Randall wrote: > On 17/05/2022 21:36, David CARLIER wrote: >> I wanted a more general but early feedback on the idea itself >> https://github.com/php/php-src/pull/3759 > > What is the motivation? What is it meant to achieve? If the Session ID continued to work as

Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions

On 16 May 2022, at 16:19, Kamil Tekiela wrote: > On 16 May 2022, at 16:06, Andreas Leathley wrote: >> https://wiki.php.net/rfc/stricter_implicit_boolean_coercions > > Has any case study been done already about how it will affect existing > codebases? The last time this happened there were no

[PHP-DEV] [Vote] MySQLi Execute Query

Hi Internals, I've just opened the vote for MySQLi Execute Query, and I'm going to close it on 2022-05-25. Discussion: https://externals.io/message/117486 RFC: https://wiki.php.net/rfc/mysqli_execute_query Thanks, Craig

[PHP-DEV] Re: MySQLi Execute Query RFC

On Thu, 21 Apr 2022 at 15:04, Craig Francis wrote: > On Wed, 6 Apr 2022 at 17:38, Craig Francis > wrote: > >> Kamil has been working on a proof of concept for a >> `mysqli_execute_query($sql, $params)` function, and I've written up a draft >> RFC for it: >

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 <mailto:cr...@craigfrancis.co.uk>> 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 numbe

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 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, <mailto:cr...@craigfrancis.co.uk>> wrote: > Not what I'm going for... but anyway, to get an idea of your position, do you

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 fav

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 <mailto:cr...@craigfrancis.co.uk>> wrote: > https://wiki.php.net/rfc/null_coercion_consistency > <https://wiki.php.net/rfc/null_coercion_consistency> > > > This

[PHP-DEV] Re: NULL Coercion Consistency

On 6 May 2022, at 16:26, Björn Larsson wrote: > Den 2022-04-08 kl. 19:34, skrev Craig Francis: >> Hi, >> I've written a new draft RFC to address the NULL coercion problems: >> https://wiki.php.net/rfc/null_coercion_consistency >> ... > > One code pattern to upg

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 attemp

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 retu

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 >>> betwe

Re: [PHP-DEV] MySQLi Execute Query RFC

On 22 Apr 2022, at 13:09, Guilliam Xavier wrote: > > https://wiki.php.net/rfc/mysqli_execute_query > > > > Thanks. Maybe add (or even start with) an example of mysqli_query(), to show > how "migrating to safer" would become easier? retro-fitting

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 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, i

[PHP-DEV] Re: MySQLi Execute Query RFC

On Wed, 6 Apr 2022 at 17:38, Craig Francis wrote: > Kamil has been working on a proof of concept for a > `mysqli_execute_query($sql, $params)` function, and I've written up a draft > RFC for it: > > https://wiki.php.net/rfc/mysqli_execute_query > > It's continuing th

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 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 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 ta

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

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 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

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 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 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 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

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 t

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);

[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

[PHP-DEV] MySQLi Execute Query RFC

Hi, Kamil has been working on a proof of concept for a `mysqli_execute_query($sql, $params)` function, and I've written up a draft RFC for it: https://wiki.php.net/rfc/mysqli_execute_query It's continuing the work Kamil has done with the "mysqli bind in execute" RFC [1], to make parameterised

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

On Wed, 2 Mar 2022 at 21:42, Alexandru Pătrănescu wrote: > What bothers me a bit is why should strlen(false) be a valid method call > but strlen(null) not so much. I think this is the inconsistency that should > be fixed so the language would be easier to work with. > Hi Alexandru, I

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

On Wed, 2 Mar 2022 at 15:21, Andreas Leathley wrote: > This is the behavior for explicit type casting (strval) and the implicit > casting when using a variable in a string context, like echo or print. > But that's what the RFC is about. Although you do raise a good point, why does

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

On Wed, 2 Mar 2022 at 14:58, Andreas Leathley wrote: > Comparisons with == are quite worthless Yep, but I'm focusing on how PHP works today, and while I welcome and encourage improvements to the language, it has to be done gracefully... forcing strict type checking on everyone (even if it's

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

On 2 Mar 2022, at 14:39, Andreas Leathley wrote: > Type coercion already often does not work - giving the string "s" to an > integer-typed argument will lead to a TypeError, it will not be coerced. > I would prefer less coercions rather than more. Hi Andreas, I'll note that converting from

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

On Wed, 2 Mar 2022 at 14:17, Larry Garfield wrote: > Null is not an empty string. Null is not a string. Null is not 0. Null > is not an integer. > So what should this do? $name = ($_POST['name'] ?? NULL); var_dump($name == ''); Is that now going to be false?

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

On Wed, 2 Mar 2022 at 12:26, Dik Takken wrote: > So, to get this crystal clear, this is my understanding of what you are > proposing for passing null to a non-nullable function parameter > (hopefully my ASCII art will come through ok): > > > which | strict_types | PHP 8.0| PHP 8.1|

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

On Tue, 1 Mar 2022 at 10:43, Christoph M. Becker wrote: > I said, the BC break doesn't appear to be *that* serious. > It is when it's a Fatal Error, and there are lots of them :-) > To elaborate: in my opinion, it is a good thing if internal functions > and userland functions behave the

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

On Tue, 1 Mar 2022 at 14:12, Kamil Tekiela wrote: > Hi Craig, > > > No, there is an inconsistency which leads to a backwards compatibility > issue, and I'm trying to fix it. > > Which inconsistency exactly do you have in mind? > Ok, let's try with code (I'll skip using variables):

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

On Tue, 1 Mar 2022 at 13:06, Christian Schneider wrote: > The other way of making internal functions behave like user land functions > would be to change the definition of the internal function to > function htmlentities(?string $value) { ... } > and casting it to string internally which

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

On Tue, 1 Mar 2022 at 09:48, Mark Randall wrote: > You see a problem, but rather than trying to fix the underlying cause, > you're proposing making changes at other layers to accommodate the side > effects of the original problem. > > That is practically the definition of a hack. > No, there

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

On Mon, 28 Feb 2022 at 22:11, Christian Schneider wrote: > Am 28.02.2022 um 22:05 schrieb Christoph M. Becker : > > The BC break doesn't appear to be that serious after all. > > I'm not sure I get your point here: If you provide a user-land > implementation of the previous behavior under a

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

On Mon, 28 Feb 2022 at 17:35, Guilliam Xavier wrote: > Call me devil's advocate, but is it too late to discuss revisiting past > decisions and consider changing direction towards 1 for userland functions > Hi Guilliam, tbh, for those who use `strict_types=1` nothing changes, so we can ignore

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

On Mon, 28 Feb 2022 at 17:42, Larry Garfield wrote: > Bringing internal functions into line with user-space was the correct > move. There may be internals functions that make sense to be nullable on > their own right, on a case by case basis. We can evaluate that case by > case. > Thanks

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

On Mon, 28 Feb 2022 at 16:41, Dik Takken wrote: > In my view, consistency between internal and userland functions brings a > lot of value, and not only for the language itself. Thanks Dik, I agree that consistency is very important, and I do not want to stop that... I just recognise that

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

On Wed, 23 Feb 2022 at 14:00, Guilliam Xavier wrote: > On Tue, Feb 22, 2022 at 3:59 AM Alexandru Pătrănescu > wrote: > > But when types are not considered important I think it's worth pursuing > > extending the coercion from null to the 4 other types where it's > happening > > right now: > > -

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

On Sat, 1 Jan 2022 at 23:17, Craig Francis wrote: > Draft RFC: > https://wiki.php.net/rfc/allow_null > To get a better idea on how I should progress this RFC, I've created a simple quiz (well, modified an old script). This is to decide if my RFC should either - continue to a

Re: [PHP-DEV] RFC proposal to deprecate crypt()

On Mon, 21 Feb 2022 at 16:44, wrote: > If crypt() is removed [...] The only thing you lose is creating those bad > password hashes. That's not exactly fair, as noted by Tim, `crypt()` can be used for other software (e.g. Dovecot); and by Hans for modifying `/etc/shadow`. While I would warn

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

On Mon, 21 Feb 2022 at 09:09, Rowan Tommins wrote: > Making the extension always available (impossible to compile without it) > is a potential option, and I think has been suggested before; I'm not > sure of the exact pros and cons. > [...] I would personally encourage everyone to have

  1   2   3   >