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 value

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 c

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

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 leve

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

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

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 ca

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

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 other

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

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

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 Service

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 can

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 Ti

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 = (isset($_GET['q'

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 years

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 addi

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 nee

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 you

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

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 handling

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 aff

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 t

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 PH

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 th

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

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 accep

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

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

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

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 reaso

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

[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://wik

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 would

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

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'], >&

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 wi

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 coe

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 no

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

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

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 t

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

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

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

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 sa

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 y

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 as

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 mo

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 nul

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

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 for

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 prefer

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 sympa

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 NULL

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 r

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 stri

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 i

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 n

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

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

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

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

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 typically

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

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 on

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 NULL

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

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 same

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): https://3v4l

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 is

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 differ

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 t

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 Larr

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 many

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

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 al

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 mo

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 ext/intl

  1   2   3   >