Re: [PHP-DEV] Empty subject in match and switch constructions

Hi, Larry! > On Feb 3, 2025, at 10:01 AM, Larry Garfield wrote: > > On Sun, Feb 2, 2025, at 7:40 AM, Ilija Tovilo wrote: >> Hi Dmitrii >> >> On Sun, Feb 2, 2025 at 1:05 PM Dmitry Derepko wrote: >> >> https://wiki.php.net/rfc/short-match >> https:

[PHP-DEV] RFC Karma Request

Hi! I’m looking for way to gain some Karma to create an RFC. I’ve already made first implementation and shared it: https://github.com/php/php-src/pull/17647 I can make 3 different RFC to discuss each change separately, let me know if it’s necessary. -- Best regards, Dmitrii Derepko.

Re: [PHP-DEV] Empty subject in match and switch constructions

Hi, Claude! > On Feb 4, 2025, at 11:44 AM, Claude Pache wrote: > > Hi, > > One issue to resolve is how to interpret: > > ```php > $x = match { > preg_match('/a/', 'a') => "will it be matched ..." > , default => "... or not?" > }; > ``` > > —Claude I wouldn’t discuss it there because the

[PHP-DEV] Re: Discussion: making continue and break into an expression

> On Jan 25, 2024, at 12:16 PM, Robert Landers wrote: > > Hello internals, > > Now that throwing is an expression, it allows for some very concise > programming. What are your thoughts on making a break/continue into an > expression as well? Hi! I had similar idea to make `break`, `continue`

Re: [PHP-DEV] RFC Karma Request

n 31, 2025 at 3:10 PM Dmitry Derepko wrote: >> >> I’m looking for way to gain some Karma to create an RFC. >> I’ve already made first implementation and shared it: >> https://github.com/php/php-src/pull/17647 >> >> I can make 3 different RFC to discuss each c

Re: [PHP-DEV] Looking for a new job

> On Mar 17, 2025, at 7:13 PM, Bilge wrote: > > On 17/03/2025 14:35, Dmitry Stogov wrote: >> Hi, >> >> I have to inform, that I'm leaving Zend in two weeks. >> Therefore I'm starting to think about a new job. >> In case some company is interested in my competence, let's start from a >> perso

Re: [PHP-DEV] Vibe check: array shapes

Hi! > However, arrays are very ergonomic to work with, especially for passing along > a list of properties, which is why many frameworks and libraries still use > them I am not agree that arrays must be typed in this way. They won’t be this arrays as they are. Instead this week I’ve started

Re: [PHP-DEV] FrankenPHP moving under the PHP GitHub organization

Jakub, what great news! Congratulations, Kevin! Bet FrankenPHP will bring the biggest step forward in the modern PHP projects. On Tue, May 13, 2025 at 10:45 PM Jakub Zelenka wrote: > Hello, > > The PHP Foundation would like to announce that it has decided to directly > support the FrankenPHP pr

Re: [PHP-DEV] RFC: Single-Expression functions

On May 26, 2025, at 11:05 PM, tovilo.ilija wrote: In the "Single-Expression functions in other languages" section, at least the Rust and Swift examples are wrong, as such a syntax does not exist for either of them. In case you got this info from an LLM, you should always fact-check whatever an A

Re: [PHP-DEV] RFC: Single-Expression functions

As Tim said, it needs at least a 2 week discussion period. Could you share the reference? Did I miss it or did I not see a PR linked from the RFC? While technically having an implementation is not a prerequisite of an RFC, it is strongly recommended. (Also, having written the original patch, I

Re: [PHP-DEV] RFC: Single-Expression functions

Thanks for your replies. There is no big deal for me to use `=>` instead of `=`. Just used to use `=`. I’ll change it then. Thought there would be more thoughts against the RFC, but the voting will show these votes. Could someone help me with the RFC process? Should I open the vote? --

Re: [PHP-DEV] RFC: Single-Expression functions

Thanks Tim for the answer. Your replies went to the Spam folder. I don't know why. I'll change the template as you suggested as soon as possible. On Tue, May 27, 2025 at 1:11 PM Tim Düsterhus wrote: > Hi > > Am 2025-05-27 09:08, schrieb Dmitry Derepko: > > As Tim sa

Re: [PHP-DEV] [RFC] Clone with v2

I really like a way with arrays. It allows users to combine what properties they want to re-set and call the clone function only once. Really good catch. On May 15, 2025, at 9:09 PM, Volker Dusch wrote:On Thu, May 15, 2025 at 12:10 AM Larry Garfield wrote:> Please include

[PHP-DEV] RFC: Single-Expression functions

Hi, Internals! I hope this message finds you well. I would like to respectfully propose single-expression functions for PHP: https://wiki.php.net/rfc/single-expression-functions I've had extensive experience working with Kotlin, which offers a modern approach to Java development and enables clean

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

Hi Larry! It's been a long, long way to get this feature, awesome work. Have you considered adding a compose function that does the same thing but in the classic PHP function style? There's not much difference between the new style: $processor = fn ($data) => htmlentities($data) |> st

[PHP-DEV] Feature Discussion |

Hello, Internals! I've implemented an alpha implementation of the Extension Functions in PHP. Basically, it's a syntax sugar of the imperative call of the function with the passing the object as a first argument, but anyway. Here is how it looks like in Kotlin: https://kotlinlang.org/docs/extensi

Re: [PHP-DEV] RFC: Single-Expression functions

I've changed the structure, followed the rfc template now. The voting section isn't available now, because the RFC is under discussion. On Tue, May 27, 2025 at 10:58 PM Dmitry Derepko wrote: > Thanks Tim for the answer. > > Your replies went to the Spam folder. I don&#

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

> > > Pipe and compose are importantly different operations. I've had > user-space implementations of both available for years in crell/fp: > https://github.com/Crell/fp/blob/master/src/composition.php > I'd love to have a compose operator natively in PHP, too. The RFC for > that is already wri

Re: [PHP-DEV] Feature Discussion |

Thanks for participating, Larry. On Mon, Jun 9, 2025 at 10:29 PM Larry Garfield wrote: > 2. Please link to a PR of your actual implementation. In context it looks > like your branch comparison link is to the version you said didn't work, so > it's not that helpful. > Correct, I don't have an

Re: [PHP-DEV] Feature Discussion |

what we have now. Can't see any problems. On Tue, Jun 10, 2025 at 11:11 PM Larry Garfield wrote: > On Tue, Jun 10, 2025, at 2:45 PM, Dmitry Derepko wrote: > > Thanks for participating, Larry. > > > > On Mon, Jun 9, 2025 at 10:29 PM Larry Garfield > wrote: > >>

[PHP-DEV] [RFC] [Discussion] CHIPS

Hi internals, In collaboration with Niels Dossche I'd like to start the discussion for an RFC proposing a new Cookie option for use with CHIPS technology. As Niels noted, today is the day when in 4 weeks there will be code freeze, so let's try to fit into the lines and deliver the value to PHP 8.

Re: [PHP-DEV] RFC: Records

Hi, Rob! I'm just wondering, why the implementation differs from a regular class? Record makes a "class" immutable and unique, using field value comparison instead of object refs. It has a custom `with` method which is similar to the new `clone` operator accepted recently. I'd suggest not intr

[PHP-DEV] [Discussion] Cookies Having Independent Partitioned State (CHIPS)

Hi, Internals! A few days ago I faced some Cookie limitations, solutions led me to the CHIPS specification. Link: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Partitioned_cookies The idea of the CHIPS implementation is to add a new Cookie part named "Partitioned".

Re: [PHP-DEV] RFC: Single-Expression functions

Hi Tim, Great questions, I’ll try to answer them all. Sorry for the late answer, looked like there are no interest in the RFC and I almost forgot about it. > On Jun 4, 2025, at 12:23 PM, Tim Düsterhus wrote: > > In the implementation I'm seeing that `$a = function() => 123;` will also > bec

Re: [PHP-DEV] [VOTE] Single-Expression Functions

> I'd like to note that the start of the vote was very surprising to me. As you > acknowledged yourself, my email regarding open questions and issues with the > RFC has been left unanswered for more the a month and then you started voting > 15 minutes after your response and making relevant ch

[PHP-DEV] [VOTE] Single-Expression Functions

Hi, Voting just opened on the "Single-Expression Functions" RFC. Please find the following resources: RFC: https://wiki.php.net/rfc/single-expression-functions Discussion: https://externals.io/message/127423 PR: https://github.com/php/php-src/pull/17677 As with every RFC, a 2/3 majority is requ

[PHP-DEV] Discussion Short Constructor

Hi, I've found a discussion about Records https://externals.io/message/125975 and found a one key point which I really like in Kotlin (hello): short constructors. Rob said that short constructor will be probably removed: 5. Inline constructor isn’t necessary and could be proposed separately.

Re: [PHP-DEV] [VOTE] Single-Expression Functions

Fixed. You saved my life, thanks! -- Best regards, Dmitrii Derepko. @xepozz

Re: [PHP-DEV] Discussion Short Constructor

Good catch for multi-classes per file with such feature, but I think it's not the time to do it. As an alternative way to find the class is to look at the all files in the namespace: src/App/Controller/ IndexController.php BlogController.php IndexController.php contains ``` namespace

[PHP-DEV] [DISCUSSION] User-land Throwable

Hello PHP Internals, I would like to propose a discussion regarding two current limitations in PHP's exception handling system that I believe could be addressed to improve flexibility and developer experience. A few years ago I found that a library printed error traces wrong. After a little resea

Re: [PHP-DEV] [DISCUSSION] User-land Throwable

On Mon, Jul 28, 2025 at 1:17 PM Tim Düsterhus wrote: > I'm afraid I don't quite understand what actual goal you intend to solve > with the proposal. The description of your use case is very abstract, > can you provide a real-world example of a use-case you want to enable? > > Best regards > Tim D

Re: [PHP-DEV] [DISCUSSION] User-land Throwable

On Mon, Jul 28, 2025 at 3:26 PM Rob Landers wrote: > > Wouldn’t a better approach be to allow serializing/deserializing > exceptions? > > — Rob > It would look like another workaround to my case. Same as deserializing data into a class to write into a private property. The simpler the better: ju

Re: [PHP-DEV] [DISCUSSION] User-land Throwable

On Mon, Jul 28, 2025 at 3:44 PM Rokas Šleinius wrote: > > On Mon, 28 Jul 2025 at 15:16, Lynn wrote: > >> >> >> On Mon, Jul 28, 2025 at 1:50 PM Rokas Šleinius wrote: >> >>> >>> On Mon, 28 Jul 2025 at 13:56, Tim Düsterhus wrote: >>> &

[PHP-DEV] [DISCUSSION] Json version of PHP Info

Hi, Internals! I want to have a unified function phpinfo() for any environment. Currently phpinfo works different in CLI and SAPI modes: - SAPI mode enforces the function print HTML tags - CLI mode enforces the function print text as is Here is implementation of the function: https://github.com/

Re: [PHP-DEV] [DISCUSSION] User-land Throwable

On Mon, Jul 28, 2025 at 8:54 PM Kamil Tekiela wrote: > > > On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote: > > IMHO the trace should be set by the engine > Agreed. It should and it should continue to do it. > it should not be possible to overwrite the getTrace method. &

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

On Thu, Jul 31, 2025 at 10:42 AM Mihail Liahimov <91lia...@gmail.com> wrote: > Hi, Rob! > > When we want to avoid returning null values, we resort to using exceptions > so that the client code can somehow handle the absence of values. > For example: > > if ($user->getName() !== null) { > $this->do

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

On Thu, Jul 31, 2025 at 10:12 AM Rob Landers wrote: > my empty catches have lengthy comments describing why they are empty in > case a user steps into it, so they can better understand how the framework > works. > > — Rob > Agree. I prefer to describe why I've wrote it: try { ... } catch (...)

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

On Thu, Jul 31, 2025 at 7:55 AM Mihail Liahimov <91lia...@gmail.com> wrote: > Introduction > > Currently, PHP requires a block body for catch clauses even when the > caught exception is not used. This results in unnecessary boilerplate code. > This RFC proposes allowing catch clauses without a bod

[PHP-DEV] Re: [VOTE] Single-Expression Functions

Hi, Internals! Unfortunately, RFC didn't pass the Voting stage: 18 people voted against, while only 6 voted for. Thank you for your attention. -- Best regards, Dmitrii Derepko. @xepozz

[PHP-DEV] Re: [DISCUSSION] Json version of PHP Info

Just want to remind you about the topic. If everyone has no objections I'll create an RFC during the next week. -- Best regards, Dmitrii Derepko. @xepozz