Re: [PHP-DEV] [RFC] Optional Catch Block Body

> Motivation > > Reduced Boilerplate: Eliminates unnecessary empty blocks when exceptions only > need to be caught and ignored. > Improved Readability: Makes the code more concise and focuses on the > important parts. > Empty `catch` blocks are a code-smell. If the `try` block is not ready to ha

Re: [PHP-DEV] pcre extended character class support

> > The reason this is opt-in in pcre2lib, is because the interpretation of > existing regexes may change. > This standard is being adopted in other languages too, also opt-in, for > example in JavaScript [1]. > To expose this functionality in PHP, we also have to make it opt-in via a > modifier

Re: [PHP-DEV] [DISCUSSION] bcmath: adding bcgetopts() and bcsetopts() to get or set bcmath options

> Would adding a bcgetopts(): int and a bcsetopts(int $opts): void calls > be useful? > > At this time there's no way to influence bcmath's behavior other than > bcscale(). > How about adding these as methods/properties to the `BcMath\Number` class? `BcMath\Number` does not use the `bcmath.scale`

Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2

> I'm not even sure it's a good idea to add those namespaced options: using > CURLOPT_SSL_VERIFYHOST is perfect to find the corresponding curl > documentation with your favorite search engine. php's doc is awesome, but it > cannot compete with the details provided by curl's doc on the topic. > >

Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2

> Hello Internals, > > I'd like to formally propose a restart of the original object-oriented > curl API RFC (https://wiki.php.net/rfc/curl-oop): > > https://wiki.php.net/rfc/curl_oop_v2 > > The prior RFC seemed to get positive feedback, with a small consensus > around wanting enum(s) for curl opti

Re: [PHP-DEV] Proposal: Support for RFC4648 in PHP

> > Why do it in core? > Is userland base16/base32 performance unsatisfactory? Even if the performance is satisfactory, having this in core can help user-land code to get rid of their own implementations (which they often do, to be URL-safe, for example). I imagine native implementations can make

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

Re: [PHP-DEV] [RFC] Modern Compression (zstd, brotli)

> First, reduce the scope of our RFC to simply add new stream wrappers for > Zstandard and Brotli similar to those already provided for zlib: > https://www.php.net/manual/en/wrappers.compression.php > To keep things moving quickly, we won't be adding any new functions or > classes (perhaps just

Re: [PHP-DEV] Allow to easily retrieve non-default INI settings / GH PR 17459

> this email concerns my PR https://github.com/php/php-src/pull/17459, > which extended the cli-SAPI’s `--ini` flag to print any INI settings > that differ from the built-in default. There was some discussion around > which flag to use, which didn't result in particularly strong opinions, Even bef

Re: [PHP-DEV] VCS Account Request: ayesh

> Thanks for the hint, I sent Ayesh an invite to the php-src team. > > Ilija I just received it and accepted the GitHub invite. Thank you so much for having me 💟 Ayesh.

Re: [PHP-DEV] VCS Account Request: ayesh

> I already approved the account. The confirmation messages that get sent to > internals were being bounced because the sender (gr...@php.net) was not > subscribed to the list. That's been fixed, so future notifications of > approved accounts should make it through. > Thank you so much Jim, I r

Re: [PHP-DEV] VCS Account Request: ayesh

> Hi Ayesh, > > I don't see a reason why we shouldn't grant you a php.net account. > > However, did you already fill-out and send the form on > ? There is apparently no account > request filed on people.php.net. > > Christoph > > I see Jim also responded about the

[PHP-DEV] VCS Account Request: ayesh

Hello Internals, My name is Ayesh Karunaratne, with GitHub username @Ayesh. In one of my recent PRs, Christoph (@cmb) made a friendly mention that it might be time for a php.net and commit karma to php-src (https://github.com/php/php-src/pull/13675#issuecomment-2373846727). I'm exci

Re: [PHP-DEV] For discussion (no RFC for now) - more libcrypt bindings

> This proposal provides more bindings: > > * crypt_gensalt($salt, $count) > * crypt_preferred_method() > * crypt_checksalt($salt) > > And more Algo > > * scrypt > * yescrypt > * gost-yescrypt > Assuming the intended use case is compatibility with `/etc/shadow` or something similar, would it not m

Re: [PHP-DEV] Proposal for New Feature: Multi-level Directory Navigation Function

> I propose the introduction of a new function, upDir(), which simplifies the > process of moving up multiple directory levels in a file path. This function > extends the utility of the existing dirname() by allowing a user to specify > the number of directory levels they wish to ascend in a sin

Re: [PHP-DEV] Where to document configuration option changes?

> In my opinion these changes should be documented in UPGRADING, but not > in UPGRADING.INTERNALS, because they are relevant for users who build > PHP themselves, packagers (aka distro managers) and the documentation > team, and neither of these is supposed to read UPGRADING.INTERNALS. And > I bel

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

> > I'm presuming it's too late for PHP 8.4, what with feature freeze having come > & gone this week. > > Based on the mostly supportive responses on the list, I wonder whether an RFC > is needed. If so, I'd be happy to create an initial draft (for PHP 8.5). > Thank you! We now have the Release

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

> Porting this to C is left as an excercise for the reader. ;) Hint: > > I went ahead and created PR https://github.com/php/php-src/pull/15443 along with tests, UPGRADE notice,

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

> There's a lot of pitfalls here, and I don't think the documentation > clearly calls out which functions are OK to use with UTF-8 and which > ones may cause unexpected surprises. > > The compatibility between ASCII and UTF-8 for Latin characters is both > a curse and a blessing. An application may

Re: [PHP-DEV] Updates needed to various RFCs

> I've fixed up the first two, but I haven't yet found the PRs regarding > the extension unbundling [snip] > I'm watching the php-src repo for some writing stuff and noted down the commits; here are the ones related to the `unbundle_imap_pspell_oci8` RFC. Hope it helps :) - Remove `pdo_oci` and

Re: [PHP-DEV] Deprecate ext/curl `CURLOPT_DNS_USE_GLOBAL_CACHE`?

> Sounds perfect. > > Fwiw CURLOPT_BINARYTRANSFER was deprecated in 8.4.0alpha without an RFC, but > it had been a no-op since 5.1.4 in 2004 Thank you! I submitted #15127[^1] that no-ops this constant. [^1]: https://github.com/php/php-src/pull/15127

Re: [PHP-DEV] Deprecate ext/curl `CURLOPT_DNS_USE_GLOBAL_CACHE`?

> Actually deprecating the constant might require the RFC process, so > maybe it's best to make it a no-op for now (and to deprecate for PHP > 8.5/9.0 whatever is next). You are right I also think making this no-op is the best way for now. Notably, Symfony HttpClient uses the constant to **disabl

[PHP-DEV] Deprecate ext/curl `CURLOPT_DNS_USE_GLOBAL_CACHE`?

Hello Internals, We recently bumped[^1] the minimum required libcurl version supported by the PHP Curl extension to 7.61.0. This aligned with the recent CentOS/RHEL 7, along with other major Linux distros that have already updated to a more recent version of libcurl. I'm writing to the Internals to

Re: [PHP-DEV] Optional constructor body

> > Hello internals. > > I am looking into making the constructor body optional in classes, > essentially allowing you to write > > ``` > class User { > public function __construct( > private string $name, > ) > } > ``` > > Currently to make this code valid, it would have to be wri

Re: [PHP-DEV] [RFC] Static class

> > This work is based on the previous discussion thread on this list of the > same name, and hopefully captured all the relevant details, > notwithstanding anything unanticipated that may present itself during > the implementation. Let me know if you feel anything important has been > missed. I am

Re: [PHP-DEV] Requiring GPG Commit Signing

> > Hi, > > What do y'all think about requiring GPG signed commits for the php-src > repository? > > I had a look, and this is also something we can enforce through GitHub > as well (by using branch protections). > > cheers, > Derick > > > -- > https://derickrethans.nl | https://xdebug.org | https:

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

> > 2024年3月9日(土) 15:26 youkidearitai : > > > > Hello, Internals > > > > I created an wiki for `grapheme_str_split` function. > > Please see: > > https://wiki.php.net/rfc/grapheme_str_split > > > > I would like to "Under Discussion" section. > > > > Best Regards > > Yuya > > > > -- > > -

Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions

> > Hi Internals, > > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. > > In particular, I am looking for any feedback as to why this is a bad > idea. The primary m

Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

> > Made a RFC draft: https://wiki.php.net/rfc/sleep_function_float_support > > First time, so I'm not surprised if there are some mistakes there. > > Feedback is very welcome. > Hi Hans, The RFC looks great, and I am personally positive to see these proposed changes implemented in PHP. One sugge

Re: [PHP-DEV] int|float for DateTime::setTimestamp

> > just like the constructor accepts > new DateTime("@0.123456"); // 1970-01-01 00:00:00.123456 > new DateTime("@".microtime(true)); > > IMO setTimestamp should accept the same: > $dt->setTimestamp(0.123456); // 1970-01-01 00:00:00.123456 > $dt->setTimestamp(microtime(true)); > > Can we change set

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

> > I see. I'll change mb_ucfirst using titlecase. > > Per my comments a month ago on the GitHub issue , I think it is much > better to use title case for mb_ucfirst() than to use upper case, > since conversion of the first character to upper case has the effect > of corrupting text in the Georgian

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

> > On Fri, Feb 2, 2024 at 2:00 AM youkidearitai > wrote: > > > Hi, Internals > > > > I have just opened the voting "Multibyte ucfirst and lcfirst functions" > > RFC. > > https://wiki.php.net/rfc/mb_ucfirst > > > > Voting will be open until February 26th, 2024 at 01:00 UTC. > > > > Cheers > > Yuya

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

> > I just encountered this language inconsistency when trying to remove > nullable from a constructor-promoted property: > > ``` > class MyClass > { > public function __construct( > public ?string $title = null // removing "?" here causes "Fatal > error: Cannot use null as default valu

Re: [PHP-DEV] Filesystem path APIs

> > There could be OOP-style alternatives too, e.g. Rust has a PathBuf struct > with methods that are used to build paths. > However if we were to choose this route then we need to be aware that > interoperability with existing filesystem functions would be much harder > because they all work di

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

> Shift_JIS is very ambiguous, What will we do if SJIS-2004 or SJIS-win comes? > How do we guess(detect) SJIS-2004, SJIS-win and SJIS-mac? I'm not the person you replied to in your previous email, but I thought to weigh in with what I can. My native language also uses multiple bytes, and have done

Re: [PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

> > try { > // do stuff > } catch(Throwable $exception) { > $this->logger->error("failed to do stuff", compact('exception')); > throw $exception; > } > I wonder why not just create an array with the key... ```php try { // do stuff } catch(Throwable $exception) { $this->logger->error("

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

> > Hi, > > > In the latter case, I suppose they would expect the behaviour to be > > compliant with the database standards. > > I may not have had this perspective. And this is a strong basis for > explaining that different drivers behave differently. > > I will continue with the current impleme

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

> More importantly, it is possible to write cross compatible code, even > without changing anything about is_resource(), if we convert streams to > opaque objects. > It might be tedious and one might need to have redundant instanceof checks > with is_resource() if one does not want to check for a f

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

> > Hi internals, > > As shown in the following issue, the behavior of `PDO::PARAM_` is > inconsistent and I would like to fix this. > https://github.com/php/php-src/issues/12603 > > First, I tried fixed pdo_pgsql. > https://github.com/php/php-src/pull/12605 > > Eventually I plan to make simil

Re: [PHP-DEV] Two new functions array_first() and array_last()

> > PHP lacks two very basic functions for working with arrays: > > - array_first() returning the first element of an array (or null) > - array_last() returning the last element of the array (or null) > > While PHP has functions that return the first and last keys, > array_key_first() and array_key

Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

> > ext/imap > > > > The library that provides the functionality in this extension, c-client, > > is no longer updated. The last release from 2007 is no longer available > > on the original distributor's (University of Washington) website, but > > there is an unofficial GitHub repository that hasn'

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

> whether returning boolean is the right thing to do at all. It seems obviously > intuitive it should, returning true for valid and false for invalid JSON > but then if you consider you're still going to be in the situation of > calling json_last_error() if you want to know why invalid JSON was inv

Re: [PHP-DEV] Removing Travis CI

Awesome, thanks a lot for this. On Mon, Jul 11, 2022 at 1:50 AM Nikita Popov wrote: > > On Sun, Jul 10, 2022 at 10:07 PM Ayesh Karunaratne wrote: >> >> Dear Internals, >> Historically, we have been using Travis CI for our automated tests, >> but since 2021

[PHP-DEV] Removing Travis CI

Dear Internals, Historically, we have been using Travis CI for our automated tests, but since 2021 June, travis-ci.org has ceased operations, and no longer runs any builds. There was an Internals discussion (https://externals.io/message/112709) to move to the successor, travis-ci.com, but I don't t

Re: [PHP-DEV] Windows PECL build machine died

With php-src's recently starting to Github Actions, would it be possible for PECL builds to use Github Actions with Windows. It supports Windows server 2016, 2019, and even 2022 (IIRC). On Fri, Apr 8, 2022 at 5:17 PM Christoph M. Becker wrote: > > Hi all, > > bad news: the Windows PECL build mach

Re: [PHP-DEV] Pre-RFC: Redacting parameters in back traces (SensitiveParameter Attribute)

Hi Tim, Thank you for opening the discussion. I personally find this feature useful, and glancing at the diff, it looks like a rather straightforward and minimal change. FWIW, it is possible to selectively expose class properties in a class object being `var_dump`-ed with the `__debugInfo` magic m

Re: [PHP-DEV] header() allows arbitrary status codes

> > Hi all, > > a while ago it has been reported[1] that our header() function actually > allows arbitrary status codes, which may even overflow. Of course, that > makes no sense, since the status code is supposed to be a three digit > code. So this ticket has been followed up by a pull request[2

Re: [PHP-DEV] PHP Foundation

Hi Nikita, Thank you so much for what you have done for PHP, the language and the community we all are in. I can't muster enough words to say how grateful I am to you for all the changes we have in PHP all these years. From every commit I see from you, to every podcast I listen to, from every PR re

Re: [PHP-DEV] Unbreak git.php.net links?

nguages, > > etc. I have added support for a static list that maps git.php.net > > names to GitHub repo under `php` organization namespace. > > > > oh i see. > > > > fwiw, your implementation looks more professional / enterprise-y :) > > > > > >

Re: [PHP-DEV] Unbreak git.php.net links?

> here is an initial implementation: > https://github.com/divinity76/git-php-net-redirector/blob/main/src/redirector.php > it is just a minimum-effort implementation, anyone feel free to make > something better (also i have no idea how the "p" argument is supposed to > be parsed, so i just guessed)

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

> > Hi internals, > > I'd like to propose the deprecation of "dynamic properties", that is > properties that have not been declared in the class (stdClass and > __get/__set excluded, of course): > > https://wiki.php.net/rfc/deprecate_dynamic_properties > > This has been discussed in various forms i

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

> I agree about the _string suffix removal. However, I know we have > parse_url() already, but parse_query() might be too generic. I would > suggest adding "http" to the name. And as we already have > http_build_query() I would rather see http_parse_query(). > +1 for http_parse_query() as it sound

Re: [PHP-DEV] RFC: autoconst

> > Hello! > > This is my first RFC proposal. I have an idea about introducing autoconst > keyword. > Motivation: > reduce duplicated code (copy/pasting constant name as value) > reducing potential typo errors in constant values > > instead of defining constants like: > const FOO = 'FOO'; > > they

Re: [PHP-DEV] Proposal: clamp

> Greetings internals, > > I present to you a proposal for a new basic math function: clamp. > > The main goal of this function is to contain a number inside a given bound. > And return the number if it is inside of that bound, and if not, and the > number is outside of the given bound, the nearest

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

> > Den søn. 6. jun. 2021 kl. 00.09 skrev Ayesh Karunaratne : > > > > Hi Ben, > > Thank you for opening this PR and the discussion. With the wide > > availability of AVIF/AV1 support in browsers, I think this will fit > > nicely. > > > > We have the

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

Hi Ben, Thank you for opening this PR and the discussion. With the wide availability of AVIF/AV1 support in browsers, I think this will fit nicely. We have the Namespaces in Bundled Extensions RFC (https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so perhaps, the new functions are

Re: [PHP-DEV] json_encode indent parameter

Hi Timon, Thank you for this RFC. I think the `string|int $indent` approach is great 🚀! Reading the PR, it looks like `$indent=0` is essentially turning off pretty-print, which I think is intuitive. Do you plan to add any sort of validation on negative integers? Perhaps throw a `\ValueError` exce

Re: [PHP-DEV] [RFC] Deprecate ticks

> > Hi Nikita, > > wt., 11 maj 2021 o 10:53 Nikita Popov napisał(a): > > > Hi internals, > > > > I'd like to propose the depreciation of the ticks mechanism: > > https://wiki.php.net/rfc/deprecate_ticks > > > > I'm submitting this separately from the PHP 8.1 deprecations RFC, as this > > is a lang

Re: [PHP-DEV] add php.ini entry to set default user_agent for curl

Hi Michael, Thanks for opening this conversation and the PR. Most HTTP client libraries that need to set a custom user agent do so with `curl_setopt` because it needs to contain a library version or some sort of dynamic values. They will likely not benefit from this change. On the other hand, libr

Re: [PHP-DEV] Changes to Git commit workflow

I think this is a great step forward. With commit signatures required, I think the person who merges a PR now needs to do so locally. [GitHub CLI](https://cli.github.com/) helps me a lot to locally checkout a PR quickly, and then rebase/squash with my own signature. Thanks to Levi Morrison and Nik

Re: [PHP-DEV] include vendor/autoload.php automatically

Larry already mentioned `auto_append_file` that I also think is the way to go, if it fits. The example directory structure from your email is also considered insecure, because without proper web-server protection, you are essentially exposing _all_ `vendor` files, including the ones that potential

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

Thank you for opening this conversation, these functions have stung me in the past, and I would be so happy to see them gone :) Personally, I would very much like to go with Plan A. - XML parsers that often deal with non-UTF-8 character encodings frequently use these functions. However, any parse

Re: [PHP-DEV] [RFC] Autoloader Classmap

Please ignore my last message :( Hi Internals, I did a somewhat rough test to compare Composer's autoloader and the function proposed in the RFC. ## TL;DR: autoload_set_classmap over Composer with OPCache: 8.12% autoload_set_classmap over Composer without OPCache: 7.93% ## Long version: Using