Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127259
Message-ID: <8a102929-9abb-446c-ad75-4c6694600f8f@varteg.nz>
Date: Thu, 1 May 2025 14:18:48 +1200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
To: internals@lists.php.net
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com>
 <ded712fb-b339-4160-8625-0f778a9c3926@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <ded712fb-b339-4160-8625-0f778a9c3926@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: Weedpacket@varteg.nz (Morgan)

On 2025-04-28 06:06, Larry Garfield wrote:
> Which is why I think we do want some kind of syntax similar to Rust's ?, so the above could be shortened back to this:
> 
> function doStuff($id): string raises UserErr {
>    $user = $repo->getUser($id) reraise;
>    // We have a good user.
> }

One thing about Rust's ?, compared with an additional "reraise" keyword 
thingy, is that the former is inline with the rest of the expression 
while the latter forces a distinct statement for each possible failure 
point. The "happy path" no longer looks quite so happy.

In other words, Rust's approach looks syntactically a lot more like 
PHP's "?->" nullsafe access, which can be looked on as addressing the 
specific case of "returning null to indicate failure" approach to error 
handling (in the even more specific case where the happy path would have 
returned an object).