Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129827 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 386C51A00BC for ; Wed, 21 Jan 2026 20:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769028152; bh=7VJCGGnotCmSAsloDY0Q0teOhtPWcyRU0XXnYKEMUA0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KO6zmP5hWsbQIsEK6BccKdFUE75u0/3dKFZSqtaJm6MOTyAmBE3IyYNh6QdGsdV/3 +SZB//QSMpLYtq+3fmXOWjEAB8CWNSuGw2KpfV4nRPwcnibP/CLRlMl/OC5/97vtht suWiGiPKuyeoNnlQnRxm2YoOSe12mE80Nu/CGlf/umgJjS3IdmekFh15XNQaWgybBU d65RQADLmYXF/6ZdHVtFcQUF87JHQ/tVHQTqqHyE/5hNebif8rMpfI5f6CeFnW79OO BDLfBsILoPwWykgHro2skH6GqYMbttFgo9MAvQVktzIcEx1OOGF75c/wIFR/S4S5Jt BNQD4EYiOO4Jw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A878A180088 for ; Wed, 21 Jan 2026 20:42:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, T_SPF_TEMPERROR autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 21 Jan 2026 20:42:28 +0000 (UTC) Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-5635f3eff8aso81885e0c.1 for ; Wed, 21 Jan 2026 12:42:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769028142; cv=none; d=google.com; s=arc-20240605; b=i8LmLL4miQwz7y0Tz5HshbCXOWtNsjnO7aFOEv1LfFpkqa2pWZy+Jf7/q5U/+EaHjw dYdi5t9/6X6xqD+EskMFfumX1RgIjZm42ysPYg/Vwyqyn5oeElnoPdVcZd4RiK4FGO0h D9orN0DwET4tBEz0VlhvmMdGuPTtuRALpa/6H+a3LebD4O6BgVQFbZAVisFHzSXeuZ7/ XiHkc+YDiLA5pFabWuvulSdwUluQHqe148NJUcU3PDDjynt1KMo3AxWk/0BXj6QP2Sv0 iPBA45wTYo39HAZIgxVHXXC1dVJNUVrA24P1oqp+fKf4VF9ZsX1+6osJQjLRX5SRpb19 aMkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=7VJCGGnotCmSAsloDY0Q0teOhtPWcyRU0XXnYKEMUA0=; fh=J5MnZTiYttcUm8J4LNyR/rFPhZBFL0iiOf3qSYgVBBE=; b=CPwRXg8BlDXeVlaekaEJ7fo5P8ZUhxrU5MqbLGhDCFmRqZAfV5CqlyQ9G4dS7H8r3C 2Z3F4gBz3JayA00RTkQvgdTe75zifActMtUZbY0gLouaXulOMoO8wERVPNQ+txlzc/xs NSygyGAYCbUtTLh1ReYfix/Y1Ndc7/M4HcEPGQ1wHNJpikk60XaOqsBDc7rjyFvXXpUV 8Huu1JnDJRn4ccm0BX7BErhxbQUYBnxOl0eoWZXhOnVninxKzDxjsgRp85nNKJzHE92C wzTOnUzsq/evFOpdYQkMwmwpVIhBRxUtSX11sxX+uUD0voHo/chCmqyOuN4Qg3+EPPCa ORyw==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769028142; x=1769632942; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7VJCGGnotCmSAsloDY0Q0teOhtPWcyRU0XXnYKEMUA0=; b=Txy3XqakSWVMVL8VwgaICfA9VWFc3KTV8ZGx1yCQCQ/DIHhmVrduLV2iscQxDIMt89 1PkL/rjvqXD06e1xyVYi+vrvEfWL1E28f0JesBCDBv4hdzRyI6kqA336oLE1VsexNlW+ FnUXlPJDyVf05UQ7aPn3WGeqESI3WaSyZWY3ZU/u6FmU+/dGAq3wmMsK9r4lN4Ta+cme MYY1fOfaT5zpy0svCbebWpQn0GDTilA9nV7m7T/9mIOVzGoz6g8YMxlokYm5kUhnI8/H n4499qKlm3NFbgZqs84DdBTGCYk28KfNP+m3xTPgPtClWGcYgAE7rMzHmSndqS0Y110E 5m2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769028142; x=1769632942; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7VJCGGnotCmSAsloDY0Q0teOhtPWcyRU0XXnYKEMUA0=; b=N6G6woZ+Y8TTFAqn+/IkHSyjC6CulsROaA0AC1QHIJ1MDCjzu/gyYbmHJ1MBP2Jucl k0NWmkpF033PCUwkymx9Yd0khidaSzvCh+ltX7/JfYSTo5+A/Swg04Q6JcyKBmmm53Ul sW2PdnsYKQh2txCyay4ggWK2/lDd/9KXyZ9tx4VaaEDQ5yy1MnH87sAG+V+8JV/CXFNx tXn2m/Iha+3sb2IR0NWhEZkJmz766EHZBgzMaNtw9edAQ8c9aMWSokk+Lej1XB9D2cOH k+nrpfhg2SIdokwywMC601RaOhTlRmNo0Wlt4YlLwDlFNiia2xkRwDRLKXd/Wkfj1/ZJ 0CSg== X-Gm-Message-State: AOJu0YwMjqG4InUnzKMP3rYV1+ziUQUXqYBmAV7a0XUSj/DAfilV6MhJ dzI5eIi9KRZq1PL5DeXmWR2tnqJ8vIvIq99JDlinkbnjAT+G9BYKo6JtRDq9J3Mxhld5b2XJ7yP AQ/yH0XjeI/mdq16398ii6hKRBjbXF+0= X-Gm-Gg: AZuq6aIdfsrxeHGYv2I57P6sxdAB8rmaf3Z4koCsAApFKg3ESUwkbiPoC659TFZdOPr 3PzFJHcRWg8ouvRQ4PAfgDGL67sGZPrZpRPoVi6ulEq3XQdLsGastd4mNAz0ujlyqRfa6astcyO bsuYsXFg9unfA+d3cB3TGMQD8RsMZdIhSNobUz/A+EfOPOXowN5049dcym6V1IHq1tTUvb5VUHL /S23XGPu14tTcS3SlEK82I1lNRlxjAtlBF/KlJhP/0Cj3YxqDnhqinpcbEPgs7cR1L+NLlLS8Xu 5LqM1w/jRpRMVn/sK9Nl+LGi/GQ= X-Received: by 2002:a05:6102:c4a:b0:5f5:2e08:bbab with SMTP id ada2fe7eead31-5f52e08c575mr623241137.6.1769028142515; Wed, 21 Jan 2026 12:42:22 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <79CDB2CC-E397-436E-B5A2-10DA1E451A97@rwec.co.uk> In-Reply-To: Date: Wed, 21 Jan 2026 22:42:10 +0200 X-Gm-Features: AZwV_Qg1l8XW6F-hI5DpB1wdvC1OvexRGWE8M1HFNios9uOBW-f5qCyc2EQIQ8s Message-ID: Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7 To: Deleu Cc: php internals Content-Type: multipart/alternative; boundary="000000000000084a420648ebf612" From: edmond.ht@gmail.com (Edmond Dantes) --000000000000084a420648ebf612 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If that were the case. But it isn=E2=80=99t. For example, the Swoole project has existed for more than 7 years. This means that anyone here can check how coroutines actually affect their code. There is already extensive experience with Laravel and other applications. All of this has existed for a long time. If people cannot read the RFC and understand that these are JavaScript-style coroutines, then why do they have votes? =F0=9F=99=82 That= =E2=80=99s a strange idea. Yes, there are issues with understanding. However, a year has passed since the publication. In one year, it should have been possible to clarify any questions, if there were any. In other words, if PHP had never had such coroutines, that could be understood. But the situation is exactly the opposite. As for trust, the problem is that people don=E2=80=99t want to waste their = time. They don=E2=80=99t want to play for a team with no chance of success. What can be done? A lot of things can be done. Last time there were several proposals. But all of these proposals go beyond the scope of the RFC. They require organizational changes. I can once again propose having two votes and an experimental mode. The first vote would be on the core principles of the language=E2=80=99s development for the next 5=E2=80=9310 years. A vote on this RFC. Or another option. There is more than one. For example, you could vote in a first approximation, and then a year later in a second round. So... =D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 22:15 Deleu : > > > On Wed, Jan 21, 2026 at 4:29=E2=80=AFPM Edmond Dantes wrote: > >> Regarding the group, I want to once again express an important point. >> The main problem, the primary blocking issue, is that nobody believes >> this RFC has any real chance. >> >> It=E2=80=99s like in the banking system: if you convince people that sto= cks >> will fall, then even if it=E2=80=99s not true, the stocks will fall. >> >> At the same time, I agree with this assessment. >> We are facing a paradox. >> >> To make changes to the language, you need to believe that these >> changes can be accepted. Previously, there were doubts about whether >> such changes could even be implemented. That problem has been solved. >> What remains is the lack of trust in acceptance. >> How can this be resolved? I think there are ways, and they are known. >> They are just all outside the scope of the current RFC. >> >> ---- >> Ed >> > > I doubt the problem is about trust. You can trust that a company will not > go bankrupt, you still need to understand how to operate and buy stocks. = I > think most readers are more likely to agree that you've put a tremendous > amount of work forward and it's not that hard to trust you've done a grea= t > job so far. But if we don't know how things work, we can't help you make > even better decisions nor can we make use of what you've built. > > I also don't think it's fair to expect from PHP's RFC process a position > of: "trust me, this is the best, lets just merge it". Even if you were th= e > best and smartest software engineer in the world, PHP is used by an > immeasurable amount of people from all backgrounds, in many contexts and > many approaches. Its not humanly possible for a single individual to know > every possible way PHP is used and the RFC process is here for people fro= m > many backgrounds to provide their own perspective of things and voice how > they think such a change will affect them or their project - be it a > positive or a negative impact. > > Right now, I think the "fairest" assumption is that we don't have many > such voices because nobody can read, understand, interpret and predict ho= w > this RFC would play out in their projects and their work. It's far too bi= g > of a change with too many concepts, mainly foreign to many people working > with PHP and there isn't a clear path of contributing to the discussion. > > How do we solve that? > > -- > Marco Deleu > --000000000000084a420648ebf612 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If that were the case. But it isn=E2=80= =99t.

For example, the Swoole = project has existed for more than 7 years. This means that anyone here can = check how coroutines actually affect their code.
The= re is already extensive experience with Laravel and other applications.
All of this has existed for a long time.

If people cannot read the RFC and und= erstand that these are JavaScript-style coroutines, then why do they have v= otes? =F0=9F=99=82 That=E2=80=99s a strange idea.
Yes, there are issues with understanding. However= , a year has passed since the publication. In one year, it should have been= possible to clarify any questions, if there were any.

In other words, if PHP had never had such co= routines, that could be understood. But the situation is exactly the opposi= te.

As for trust, the pr= oblem is that people don=E2=80=99t want to waste their time. They don=E2=80= =99t want to play for a team with no chance of success.

What can be done? A lot of things can be do= ne. Last time there were several proposals. But all of these proposals go b= eyond the scope of the RFC. They require organizational changes.

I can once again propose having tw= o votes and an experimental mode.
The first vote wou= ld be on the core principles of the language=E2=80=99s development for the = next 5=E2=80=9310 years.
A vote on this RFC.
Or another option. There is more than one. For example, you= could vote in a first approximation, and then a year later in a second rou= nd.

So...=C2=A0

=D1= =81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 22:15 Deleu <del= eugyn@gmail.com>:


On Wed, Jan 21, 2026 at 4:29=E2=80=AFPM Edmon= d Dantes <edmond.ht@gmail.com> wrote:
Regarding the group, I want to = once again express an important point.
The main problem, the primary blocking issue, is that nobody believes
this RFC has any real chance.

It=E2=80=99s like in the banking system: if you convince people that stocks=
will fall, then even if it=E2=80=99s not true, the stocks will fall.

At the same time, I agree with this assessment.
We are facing a paradox.

To make changes to the language, you need to believe that these
changes can be accepted. Previously, there were doubts about whether
such changes could even be implemented. That problem has been solved.
What remains is the lack of trust in acceptance.
How can this be resolved? I think there are ways, and they are known.
They are just all outside the scope of the current RFC.

----
Ed

I doubt the problem is= about trust. You can trust that a company will not go bankrupt, you still = need to understand how to operate and buy stocks. I think most readers are = more likely to agree that you've put a tremendous amount of work forwar= d and it's=C2=A0not that hard to trust you've done a great job so f= ar. But if we don't know how things work, we can't help you make ev= en better decisions nor can we make use of what you've built.

I also don't think it's fair to expect from PHP'= ;s RFC process a position of: "trust me, this is the best, lets just m= erge it". Even if you were the best and smartest software engineer in = the world, PHP is used by an immeasurable amount of people from all backgro= unds, in many contexts and many approaches. Its not humanly possible for a = single individual to know every possible way PHP is used and the RFC proces= s is here for people from many backgrounds to provide their own perspective= of things and voice how they think such a change will affect them or their= project - be it a positive or a negative impact.

= Right now, I think the "fairest" assumption is that we don't = have many such voices because nobody can read, understand, interpret and pr= edict how this RFC would play out in their projects and their work. It'= s far too big of a change with too many concepts, mainly foreign to many pe= ople working with PHP and there isn't a clear path of contributing to t= he discussion.

How do we solve that?
--
Mar= co Deleu
--000000000000084a420648ebf612--