Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

On Wednesday, 30 April 2025 at 13:16, Christian Schneider wrote: > Am 27.04.2025 um 20:22 schrieb Gina P. Banyard intern...@gpb.moe: > > > I fundamentally reject the concept of this RFC to restrict our ability to > > do input validation. > > > I am sorry but I fail to see how the RFC restric

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On Wednesday, 7 May 2025 at 20:20, Paul M. Jones wrote: > Hi Maté and all, > > > On May 5, 2025, at 16:36, Máté Kocsis kocsismat...@gmail.com wrote: > > > > Hello Internals, > > > > After more than a hundred emails refining even the tiniest details, we have > > reached a point where I'd like

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, > On May 5, 2025, at 16:36, Máté Kocsis wrote: > > Hello Internals, > > After more than a hundred emails refining even the tiniest details, we have > reached a point where I'd like to call for a vote. > I know that the new API still doesn't support many use-cases, it still has

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hello Internals, After more than a hundred emails refining even the tiniest details, we have reached a point where I'd like to call for a vote. I know that the new API still doesn't support many use-cases, it still has missing pieces, but now it includes a cohesive set of functionality that could

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Paul, I would not presume that the dedicated value objects are what "makes the > [Rowbot] library much slower" than the RFC -- instead, my first intuition is that the *parsing* operations are slower in userland > than in C, and are primarily responsible for the comparative slowness. Speedwise

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hey Ignace, > I see you updated the RFC but I believe there's still some errors in the > example: > $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws > Uri\WhatWg\InvalidUrlException because of $baseUri > After following the suggestion of Tim, I changed the type of the $baseUrl parameters

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, Why can't the Url::resolve method also expose the `$errors` parameter like > the constructor and the parse static method ? As far as I understand it > nothing prevents the API from exposing the errors during URI resolution > which is a proxy method for the constructor call just like the

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, I have just added the SensitiveParameter attribute to the Uri\Rfc3986\Uri::withUserInfo() and Uri\WhatWg\Url::withPassword() methods. > Reading the WHATWG URL specification and checking how > >- Chrome, >- Firefox >- and even https://github.com/TRowbotham/URL-Parser > > >

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Wed, 30 Apr 2025 at 21:13, Larry Garfield wrote: > >> […] just that it's the only time I've seen $code used in the wild... > >> > > > > PDO (for better or worse) also uses the `$code` for the error code > > returned by the database. Unfortunately it also widens the (untyped) > > $code from int

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Wed, Apr 30, 2025, at 1:06 PM, Tim Düsterhus wrote: > Hi > > On 4/30/25 15:33, Larry Garfield wrote: >> The only time I've seen anyone use $code is in TYPO3. Their coding >> standards say that any time you throw an exception, you use the current >> timestamp (determined manually) as a code.

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/30/25 13:18, Derick Rethans wrote: - Exceptions MUST NOT be ``final``. Could the RFC explain why not? I'm not sure if this is useful to add to the RFC itself as a “only extra explanation” and since the discussion is an equally official resource: The reason is to allow flexible exte

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/30/25 15:33, Larry Garfield wrote: The only time I've seen anyone use $code is in TYPO3. Their coding standards say that any time you throw an exception, you use the current timestamp (determined manually) as a code. That way there is a globally unique code regardless of exception t

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Máté and Tim Why can't the Url::resolve method also expose the `$errors` parameter like the constructor and the parse static method ? As far as I understand it nothing prevents the API from exposing the errors during URI resolution which is a proxy method for the constructor call just like the

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Wed, Apr 30, 2025, at 6:18 AM, Derick Rethans wrote: > On Sun, 27 Apr 2025, Tim Düsterhus wrote: > - Any two exceptions with different causes MUST be identifiable either > by a unique exception class name, a stable ``$code``, or a > class-specific additional property suitable for programm

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Am 27.04.2025 um 20:22 schrieb Gina P. Banyard : > I fundamentally reject the concept of this RFC to restrict our ability to do > input validation. I am sorry but I fail to see how the RFC restrict the ability to do input validation. > Emitting an E_DEPRECATED for invalid inputs remains utter n

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Sun, 27 Apr 2025, Tim Düsterhus wrote: > Hi > > as announced in the URI RFC discussion thread > (https://externals.io/message/123997#127142), I've now written up an > “Exception Hierarchy” policy RFC together with Gina. > > Please find the following links: > > RFC: https://wiki.php.net/rfc/e

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Máté and Tim I read the following in the RFC >Withers of Uri\WhatWg\Url follow the relevant “setter steps” that are defined by WHATWG URL. Unfortunately, these algorithms sometimes have surprising behavior where modification fails silently, and t

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Paul, I will try to address your concerns. Keep in mind that I am not the author of the RFC but I do like how it is currently shaped with some caveats but those can be put under future improvements. > So, one value added by splitting the classes is to resolve that asymmetry. First, I agree wi

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi On 4/29/25 10:54, ignace nyamagana butera wrote: I have one last question while reviewing my polyfill implementation. Is it worth it adding a SensitiveParameter attribute on the argument of the following methods ? - Uri\Rfc3986\Uri::withUserInfo - Uri\WhatWg\Url::withPassword I'm fine with

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace & Maté and all, tl;dr: I argue against Ignace's objections to splitting the URI class into two classes (one that retains raw URI values and another that normalizes values as-it-goes). Jump to the very end for a discussion regarding the with() methods (search for the word "asymmetry" h

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and Time, I have one last question while reviewing my polyfill implementation. Is it worth it adding a SensitiveParameter attribute on the argument of the following methods ? - Uri\Rfc3986\Uri::withUserInfo - Uri\WhatWg\Url::withPassword I'm fine with any answer ? Does it warrant a parag

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/29/25 00:36, Larry Garfield wrote: It's a common recommendation in userland, as it allows implementers to extend an existing exception (eg, InvalidArgumentException) of their choice while still being tagged as coming from a given library. Though I suppose if the policy doc also says

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Mon, Apr 28, 2025, at 4:27 PM, Tim Düsterhus wrote: > Hi > > On 4/28/25 23:09, Larry Garfield wrote: * Would allowing an extension-tagging interface instead of a base class be an option? It still allows for catching "anything thrown by this extension", which I presume is the go

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté, > I fiddled a little bit with the implementation, and I went with the Uri\UriComparisonMode enum name at last. I hope that it is OK on your side. If no one objects with your name choice I am fine with it, as long as it is not a boolean :) I will adapt my polyfill. I think I have no more

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/28/25 23:09, Larry Garfield wrote: * Would allowing an extension-tagging interface instead of a base class be an option? It still allows for catching "anything thrown by this extension", which I presume is the goal. If not, why? See the “Choice of Base Exception” section in https:/

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, The $excludeFragment is `true` by default so in the example it should be > `false` instead. Perhaps using an Enum instead would make the > DX easier than using a boolean ? > I believe the same issue is in all examples regarding the use of that > parameter. > You are right, I completely

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Mon, Apr 28, 2025, at 3:30 PM, Tim Düsterhus wrote: > Hi > > On 4/28/25 22:04, Larry Garfield wrote: >> Holy cow, thank you for this bit. The inability to tell what went wrong >> programmatically without string parsing the exception message is one of my >> biggest pet peeves in current except

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Paul, > The Rfc3986\Uri `raw()` methods present a departure from existing userland expectations when working with URIs. No existing URI package that I'm aware of retains the normalized values as their "main" values; the values are generally retained-as-given (i.e. "raw"). Nor do they afford get

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/28/25 22:04, Larry Garfield wrote: Holy cow, thank you for this bit. The inability to tell what went wrong programmatically without string parsing the exception message is one of my biggest pet peeves in current exceptions. Anything particular from the standard library? It might be

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Sun, Apr 27, 2025, at 4:45 PM, Tim Düsterhus wrote: > Hi > > On 4/27/25 23:16, Kamil Tekiela wrote: >> The exception message MUST NOT be the only means of distinguishing >> exceptions. Any two exceptions with different messages MUST be >> identifiable either by a unique exception class name or c

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, > On Apr 27, 2025, at 16:47, Máté Kocsis wrote: > > Hi Tim, ... >> So it seems to be safer to use the naming without the `raw` and then in >> the documentation explain what happens with useful examples, just like >> the RFC already does. > > We discussed this off the list, an

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On Mon, Apr 28, 2025 at 9:05 AM ignace nyamagana butera wrote: > Hi Maté, > > I found another typo in the RFC examples due to the use of boolean as > parameters > > // The fragment component of Uri\WhatWg\Url can also be taken into > account$url = new Uri\WhatWg\Url("https://example.com#foo";);$

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté, I found another typo in the RFC examples due to the use of boolean as parameters // The fragment component of Uri\WhatWg\Url can also be taken into account$url = new Uri\WhatWg\Url("https://example.com#foo";);$url->equals(new Uri\WhatWg\Url("https://example.com";), true); // false The $

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi On 4/27/25 23:47, Máté Kocsis wrote: […] Thank you. I have just given the RFC another full read (the 2025/04/27 21:44 version) and I do not have any further remarks. I'm happy with everything that is said in the RFC and I'm really looking forward to vote “Yes” :-) Best regards Tim Düst

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, > In https://news-web.php.net/php.internals/127114 I suggest to only > provide the "non-raw" methods, so I believe you misread that. I've just > given the RFC another read and thought about the naming and I believe I > still prefer not having the "raw" in the name: > > - Having the `raw`

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/27/25 23:16, Kamil Tekiela wrote: The exception message MUST NOT be the only means of distinguishing exceptions. Any two exceptions with different messages MUST be identifiable either by a unique exception class name or code. Thank you. I have used that as the basis for this change: h

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

>Do you have a wording suggestion to make it clearer what is meant by that sentence? How about this: The exception message MUST NOT be the only means of distinguishing exceptions. Any two exceptions with different messages MUST be identifiable either by a unique exception class name or code.

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi On 4/27/25 22:50, ignace nyamagana butera wrote: I understand that but then I fail to see the added value of the parse method vs the default constructor since from the RFC the only difference is that the parse named constructor should instead of throwing return null. If the parse method can s

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Sun, Apr 27, 2025, at 22:40, Kamil Tekiela wrote: > >The exception message MUST NOT be the only property that allows to > differentiate different types of error that the user may be interested in. > > What does this mean exactly? Can you give an example? > Many people don’t know about the $

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/27/25 22:40, Kamil Tekiela wrote: The exception message MUST NOT be the only property that allows to differentiate different types of error that the user may be interested in. What does this mean exactly? Can you give an example? This is intended to say “if a user calls ->getMessage(

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Le dim. 27 avr. 2025, 22:32, Tim Düsterhus a écrit : > Hi > > On 4/27/25 22:30, ignace nyamagana butera wrote: > > $url = Uri\WhatWg\Url::parse("/foo", ".com"); // > > Throws Uri\WhatWg\InvalidUrlException because of $baseUri > > > > Since parse is used shouldn't it return null in

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

>The exception message MUST NOT be the only property that allows to differentiate different types of error that the user may be interested in. What does this mean exactly? Can you give an example?

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi On 4/27/25 22:30, ignace nyamagana butera wrote: $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws Uri\WhatWg\InvalidUrlException because of $baseUri Since parse is used shouldn't it return null instead of throwing ? In this case the `$baseUri` is invalid. Since this

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté I see you updated the RFC but I believe there's still some errors in the example: $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws Uri\WhatWg\InvalidUrlException because of $baseUri Since parse is used shouldn't it return null instead of throwing ? $uri = Uri\Rfc

[PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi as announced in the URI RFC discussion thread (https://externals.io/message/123997#127142), I've now written up an “Exception Hierarchy” policy RFC together with Gina. Please find the following links: RFC: https://wiki.php.net/rfc/extension_exceptions Policy PR: https://github.com/php/pol

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Thank you all for the feedback. > I don't fundamentally disagree with the attempt to codify something > here, but ultimately the PHP language does and will continue to profit > from some flexibility in these regards. @Bob, I agree that flexibility is desired. That's why I would like to have rathe

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

On Sunday, 13 April 2025 at 22:07, Jorg Sowa wrote: > Thank you all for the feedback on the topic of BC breaks in argument > validation https://news-web.php.net/php.internals/126706 > > I have collected all concerns, prepared an RFC for this change, and I'm > opening discussion on its content:

Re: [PHP-DEV] [RFC] [Vote] array_first() and array_last()

On Tue, Apr 22, 2025 at 9:18 PM Niels Dossche wrote: > > Hi internals > > I'm opening the vote for https://wiki.php.net/rfc/array_first_last > Vote runs until 2025-05-06 23:59:59 CEST. > > Kind regards > Niels I've voted yes. I still don't like functions which conflate null as an error and null a

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Am 2025-04-17 13:18, schrieb Máté Kocsis: Sweet. I believe this was/is the last remaining blocker for the RFC or is there still anyone else from your side that needs to be discussed? I need to give the RFC another read once you made the adjustment to remove the WhatWg raw methods (and adju

[PHP-DEV] [RFC] [Vote] array_first() and array_last()

Hi internals I'm opening the vote for https://wiki.php.net/rfc/array_first_last Vote runs until 2025-05-06 23:59:59 CEST. Kind regards Niels

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, A one-off comment about the exceptions: The RFC posits that _Uri\UriException_ extends _Exception_, and _Uri\InvalidUriException_ extends _UriException_. However, pre-existing userland solutions to the URI problem lean more heavily on the native PHP _InvalidArgumentException_,

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi On 4/17/25 23:14, Paul M. Jones wrote: On 4/17/25 22:47, Paul M. Jones wrote: As such, the _InvalidUriException_ would better extend from _LogicException_. No. There is a de facto policy of “not using SPL exceptions in new code”. The replacement for LogicException is the Error hierarchy.

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> On Apr 17, 2025, at 15:58, Tim Düsterhus wrote: > > Hi > > On 4/17/25 22:47, Paul M. Jones wrote: >> As such, the _InvalidUriException_ would better extend from _LogicException_. > > No. There is a de facto policy of “not using SPL exceptions in new code”. The > replacement for LogicExcep

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi On 4/17/25 22:47, Paul M. Jones wrote: As such, the _InvalidUriException_ would better extend from _LogicException_. No. There is a de facto policy of “not using SPL exceptions in new code”. The replacement for LogicException is the Error hierarchy. Also, as you quoted yourself, LogicExc

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, > Currently the path is nullable but according to the RFC the path can not > be nullable > According to the RFC the path can have up to 5 ABNF representation > Uh, this is something that I also forgot to sync between the implementation and the RFC. I also recently found out that the g

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, > Uh, this is something that I also forgot to sync between the > implementation and the RFC. I also recently found out that > the get*Path() methods should be non-nullable for both classes, so I > recently fixed them. Sorry for the confusion! > Actually, I realized after checking the

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

I still have one last question regarding the RFC3986 URI path component. Currently the path is nullable but according to the RFC the path can not be nullable According to the RFC the path can have up to 5 ABNF representation > path = path-abempty ; begins with "/" or is empty

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi, Tim Düsterhus ezt írta (időpont: 2025. ápr. 17., Cs, 9:22): > Hi > > Am 2025-04-15 23:55, schrieb Máté Kocsis: > > This was one of my (unspoken) ideas as well. I used to think there must > > have been a correct logic > > for percent-decoding of WHATWG components, but if none of us can come

Re: [PHP-DEV] RFC: blank() Function as a Complement to empty()

Hi Am 2025-04-07 09:14, schrieb Rowan Tommins [IMSoP]: I think a function for "string is zero length or contains only whitespace" would potentially be useful And for that one it would need to be defined what whitespace is. Is it just the ASCII whitespace characters? Is it Unicode whitespace?

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Am 2025-04-15 23:55, schrieb Máté Kocsis: This was one of my (unspoken) ideas as well. I used to think there must have been a correct logic for percent-decoding of WHATWG components, but if none of us can come up with a sensible idea, then it's best not to try it, I agree. Sweet. I believ

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, > Perhaps the correct solution would be to offer only the non-raw methods > for WHATWG URL and to not attempt any additional percent-decoding there? > My reasoning is that the WHATWG URL is a living standard anyways, so > trying to add additional semantics on top will result in sadness. M

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Perhaps the correct solution would be to offer only the non-raw methods for WHATWG URL and to not attempt any additional percent-decoding there? My reasoning is that the WHATWG URL is a living standard anyways, so trying to add additional semantics on top will result in sadness. My understandin

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Am 2025-04-13 14:10, schrieb Máté Kocsis: namespace Uri { class InvalidUriException extends \Uri\UriException { } } namespace Uri\WhatWg { class InvalidUrlException extends \Uri\InvalidUriException { /** @var list */

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Hi, On Sun, Apr 13, 2025 at 11:09 PM Jorg Sowa wrote: > Thank you all for the feedback on the topic of BC breaks in argument > validation https://news-web.php.net/php.internals/126706 > > I have collected all concerns, prepared an RFC for this change, and I'm > opening discussion on its content:

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Hey Jorg, On 13.4.2025 23:07:07, Jorg Sowa wrote: I have collected all concerns, prepared an RFC for this change, and I'm opening discussion on its content: https://wiki.php.net/rfc/minor-version-compatibility Let me address some parts of the RFC: - The secondary vote #1 requires the same h

[PHP-DEV] [RFC] [Discussion] Minor version compatibility

Thank you all for the feedback on the topic of BC breaks in argument validation https://news-web.php.net/php.internals/126706 I have collected all concerns, prepared an RFC for this change, and I'm opening discussion on its content: https://wiki.php.net/rfc/minor-version-compatibility Since this

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

On 13/04/2025 15:07, Kamil Tekiela wrote: This discussion seems to have overlooked that the setting doesn't just restrict the*display* of arguments, it restricts the*collection* of those arguments into the Exception object, which has visible effects on the behaviour and performance of the program

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

>This discussion seems to have overlooked that the setting doesn't just restrict the *display* of arguments, it restricts the *collection* of those arguments into the Exception object, which has visible effects on the behaviour and performance of the program. Oh, I didn't know that. I assumed the

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, I think I would prefer: > > namespace Uri { > class InvalidUriException extends \Uri\UriException > { > } > } > > namespace Uri\WhatWg { > class InvalidUrlException extends \Uri\InvalidUriException { > /** @var list */ >

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

On 09/04/2025 03:00, Andrew Lyons wrote: Hi everyone, I've been working on a new RFC which proposes changing the default value for the zend.exception_ignore_args INI setting from Off to On. The intent of this change is to make PHP installations safer by default and prevent the accidental rel

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

> In an ideal world they are never revealed to the end user, but real-world solutions fall short. It's not uncommon for people to have display_errors enabled for some reason or another. It is also possible for sites to be misconfigured, or for applications to make mistakes and accidentally dump sta

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

> I can't find any information on why this setting was introduced. No, I couldn't find anything either. I did try to investigate and all I could find was that it was introduced by Joe Watkins in 0819e6dc9b4788e5d44b64f8e606a56c969a1588 in 2019 but I haven't been able to find any history of RFC or

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

> > Full agreement with Tim here - make PHP friendly to development. Generally I do agree with this sentiment. Languages should be developer-friendly, but not at the expense of safety. Developers are able to configure an INI setting in multiple ways including modifying an ini file, using the `ini

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

On Thu, 10 Apr 2025 at 23:20, Tim Düsterhus wrote: > As I had said on GitHub before, but to put it onto the list for > visibility: > > I'd rather see the value in `php.ini-production` being changed to `Off` > to match the built-in default. see > https://github.com/php/php-src/pull/18215#issuecomme

Re: [PHP-DEV] [RFC] Pipe Operator (again)

Hi Larry Sorry again for the delay. On Fri, Apr 4, 2025 at 6:37 AM Larry Garfield wrote: > > * A new iterable API is absolutely a good thing and we should do it. > * That said, we *need* to split Sequence, Set, and Dictionary into separate > types. We are the only language I reviewed that didn

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

I can't find any information on why this setting was introduced. I guess that it was either to protect sensitive information or to reduce verbosity in the logs, but either one seems like a poor reason for this setting to exist. The INI comment seems to suggest that it was introduced to protect sens

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

On Thu, Apr 10, 2025, at 1:53 PM, Bob Weinand wrote: >> I'd rather see the value in `php.ini-production` being changed to >> `Off` to match the built-in default. see >> https://github.com/php/php-src/pull/18215#issuecomment-2768618516 > > > Full agreement with Tim here - make PHP friendly to dev

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

Hey, On 10.4.2025 17:19:57, Tim Düsterhus wrote: Hi Am 2025-04-09 04:00, schrieb Andrew Lyons: The intent of this change is to make PHP installations safer by default and prevent the accidental release of sensitive information in stack traces. * RFC: https://wiki.php.net/rfc/exception_ignore

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On 06/04/2025 19:06, Juris Evertovskis wrote: > On 2025-04-05 18:51, Niels Dossche wrote: > Do you think it would be hard or wrong to add `array_nth`? I've had more > trouble with that as the in-place implementation is usually pretty > unreadable, e.g. > >     array_slice(array_values($array), $

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hey Ignace, (let me answer in the original thread, as apparently the discussion continued in a separate thread from the main one) > - I believe during normalization of IPv6 host the letter a-f should be > lowercase in accordance with the RFC since > > RFC3986 follows https://www.rfc-editor.org/rf

Re: [PHP-DEV] [RFC] Pipe Operator (again)

On Wed, Apr 9, 2025, at 12:56 AM, Rob Landers wrote: > On Wed, Apr 9, 2025, at 01:29, Ilija Tovilo wrote: >> Hi Larry >> >> Sorry again for the delay. >> >> On Fri, Apr 4, 2025 at 6:37 AM Larry Garfield wrote: >> > >> > * A new iterable API is absolutely a good thing and we should do it. >> > *

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

Hi Am 2025-04-09 04:00, schrieb Andrew Lyons: The intent of this change is to make PHP installations safer by default and prevent the accidental release of sensitive information in stack traces. * RFC: https://wiki.php.net/rfc/exception_ignore_args_default_value * Implementation: https://gith

Re: [PHP-DEV] [RFC] Pipe Operator (again)

On Wed, Apr 9, 2025, at 01:29, Ilija Tovilo wrote: > Hi Larry > > Sorry again for the delay. > > On Fri, Apr 4, 2025 at 6:37 AM Larry Garfield wrote: > > > > * A new iterable API is absolutely a good thing and we should do it. > > * That said, we *need* to split Sequence, Set, and Dictionary int

[PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

Hi everyone, I've been working on a new RFC which proposes changing the default value for the zend.exception_ignore_args INI setting from Off to On. The intent of this change is to make PHP installations safer by default and prevent the accidental release of sensitive information in stack traces.

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On 4/8/25 10:53 AM, Daikaras wrote: > On 4/5/2025 6:51 PM, Niels Dossche wrote: >> Hi internals >> >> I'm opening the discussion for the RFC "array_first() and array_last()". >> https://wiki.php.net/rfc/array_first_last >> >> Kind regards >> Niels > > > -1 because returning `null` for empty array

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On 4/8/25 8:46 PM, Claude Pache wrote: > Hi, > > I think that this argument is not convincing, and even counterproductive: > > * NULL is a rare legitimate value, so the potential for clashing is low > > First, it says that it is a “rare” legitimate value, which one can disagree > with. (I do di

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On 4/8/25 10:53 AM, Daikaras wrote: > On 4/5/2025 6:51 PM, Niels Dossche wrote: >> Hi internals >> >> I'm opening the discussion for the RFC "array_first() and array_last()". >> https://wiki.php.net/rfc/array_first_last >> >> Kind regards >> Niels > > > -1 because returning `null` for empty array

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On Sat, Apr 5, 2025, at 10:51 AM, Niels Dossche wrote: > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels To add another argument: the reset() workaround doesn't work with a readonly arra

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

> Le 5 avr. 2025 à 17:51, Niels Dossche a écrit : > > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels Hi, I think that this argument is not convincing, and even counterproductive:

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On Tue, 8 Apr 2025 at 18:38, Levi Morrison wrote: > > On Sat, Apr 5, 2025 at 9:51 AM Niels Dossche wrote: > > > > Hi internals > > > > I'm opening the discussion for the RFC "array_first() and array_last()". > > https://wiki.php.net/rfc/array_first_last > > > > Kind regards > > Niels > > I dislik

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On Mon, 7 Apr 2025 at 02:48, Ayesh Karunaratne wrote: > > > On Mon, Apr 7, 2025 at 2:05 AM Bilge wrote: > > ... [snip] I suggest first proving there is a > > legitimate need. > > I did a quick GitHub search for a common pattern of accessing an array > value by using the `array_key_first` and `arr

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On Tue, Apr 8, 2025, at 10:53, Daikaras wrote: > On 4/5/2025 6:51 PM, Niels Dossche wrote: > > Hi internals > > > > I'm opening the discussion for the RFC "array_first() and array_last()". > > https://wiki.php.net/rfc/array_first_last > > > > Kind regards > > Niels > > > -1 because returning `n

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On Sat, Apr 5, 2025 at 9:51 AM Niels Dossche wrote: > > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels I dislike all the functions where `null` is a valid value, which can also be confu

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On 4/5/2025 6:51 PM, Niels Dossche wrote: Hi internals I'm opening the discussion for the RFC "array_first() and array_last()". https://wiki.php.net/rfc/array_first_last Kind regards Niels -1 because returning `null` for empty arrays is still wrong. Whatever similar behavior exists should b

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, it might be brought back for future improvements. > > Yes, surely! > I have one last question regarding the URI implementations which are raised > by my polyfill: > > Did you also took into account the delimiters when submitting data via the > withers ? In other words is > > ```php

Re: [PHP-DEV] RFC: blank() Function as a Complement to empty()

>If this can still be implemented in userland you don't need logic integrated >at low level Afaik it cannot be implemented in userland today. The closest you can get today is to use reference hacks, which introduce side-effects, like if you do function blank(&$value){...} blank($_POST['foo']) an

Re: [PHP-DEV] RFC: blank() Function as a Complement to empty()

On 5 April 2025 21:00:15 BST, Rob Landers wrote: >I agree with most of these. I do not agree that " " (a space) is blank though. >For people without last names, this is often their last name to pass >validation on forms. This is firmly into "space-bar heating" [https://xkcd.com/1172/] terr

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On 07/04/2025 01:47, Ayesh Karunaratne wrote: On Mon, Apr 7, 2025 at 2:05 AM Bilge wrote: ... [snip] I suggest first proving there is a legitimate need. I did a quick GitHub search for a common pattern of accessing an array value by using the `array_key_first` and `array_key_last` functions: `

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

On Sun, Apr 6, 2025, at 7:47 PM, Ayesh Karunaratne wrote: >> On Mon, Apr 7, 2025 at 2:05 AM Bilge wrote: >> ... [snip] I suggest first proving there is a >> legitimate need. > > I did a quick GitHub search for a common pattern of accessing an array > value by using the `array_key_first` and `array

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

> On Mon, Apr 7, 2025 at 2:05 AM Bilge wrote: > ... [snip] I suggest first proving there is a > legitimate need. I did a quick GitHub search for a common pattern of accessing an array value by using the `array_key_first` and `array_key_last` functions: ```php $value = $arr[array_key_first($resul

  1   2   3   4   5   6   7   8   9   10   >