Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127224
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 28 Apr 2025 09:18:35 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <150fb4df-47a4-4ab3-8edb-13e446b122cc@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8C1B68YU-369vjW1ui2iq1KS+kVE0m=hDdAiHSV-FKhJw@mail.gmail.com>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com>
 <ded712fb-b339-4160-8625-0f778a9c3926@app.fastmail.com>
 <CAMW7n8C1B68YU-369vjW1ui2iq1KS+kVE0m=hDdAiHSV-FKhJw@mail.gmail.com>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Apr 28, 2025, at 6:46 AM, Edmond Dantes wrote:

> Later in the letter you explain in more detail that this is *not a 
> special kind of exception*, nor a new execution flow, but rather a* 
> special type of result*.  
>
> But if this is a special type of result, then it should follow *the 
> same rules as all PHP types*.  In other words, this cannot be solved 
> without generics. 

I do not understand that statement in the slightest.  I have already demonstrated how it can be solved without generics.  Multiple response channels from a function already exist: Normal returns and exceptions.  Exceptions as currently designed are just very poorly suited to the problem space I am describing.

> However, the benefit of the new syntax, which could make the code 
> cleaner, does not depend on generics:  
> For example:  
>
> ```php 
> $res = someFunction() catch ($err) {throw $err;} // Like Zig? 
> ```

A way to simplify try-catch syntax is certainly a possible side effect of this feature, though that is secondary to the point I am making.

> However, it seems to me that we can achieve the same result using 
> `throw`, simply by adding new syntax and capabilities.  Yes, there may 
> be some backward compatibility issues, but is it really something to be 
> afraid of?

See other threads going on right now debating what BC breaks are acceptable and which are not.  And let's not forget that every release there is an outcry of "OMG you broke my app!" for even the smallest deprecation of something widely acknowledged to be bad practice anyway.  We should absolutely not be flippant about BC breaks in behavior.

--Larry Garfield