Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124773
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 05 Aug 2024 10:46:07 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <ef8e41f8-c5dc-4682-81ec-01731c8f53ee@app.fastmail.com>
In-Reply-To: <1a8650d2-7eb5-d645-8132-e5522ad24637@php.net>
References: 
 <WAN6ETlWt7JfcVoyeYfY_F_eLE6WzQa87F7yi8SHISmyktMYx7YcA6oG5dis3gFeI36VBjSfjGw4AT6psFFDXEUNRrvKRRn4LxfdCxFBccw=@gpb.moe>
 <15bb76a0-cbd7-4145-b429-76d424755106@gmx.de>
 <1a8650d2-7eb5-d645-8132-e5522ad24637@php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a
 standard function
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Aug 5, 2024, at 6:04 AM, Derick Rethans wrote:
> On Tue, 30 Jul 2024, Christoph M. Becker wrote:
>
>> On 30.07.2024 at 11:49, Gina P. Banyard wrote:
>> 
>> > I have just opened the vote for the "Transform exit() from a 
>> > language construct into a standard function" RFC: 
>> > https://wiki.php.net/rfc/exit-as-function
>> >
>> > The vote will last for two weeks until the 13th of August 2024.
>> 
>> As userland PHP developer, I always regarded `exit` as a control flow 
>> instruction (quite similar to `break`), and as such I'm not really in 
>> favor of converting it to a proper function (especially since it is 
>> not, because the parantheses could be omitted).
>
> Xdebug uses exit for exactly that too. For control flow analysis. And I 
> also always have considered it to be a control flow instruction.
>
> I see no benefit in changing it to a function, especially because 
> there will never be a function "exit" from it, just only an "entry". 
> This breaks function execution symmetry (and causes issues with Xdebug 
> when I last tried to make it work with a development branch for this 
> RFC).
>
> As the RFC is scarce on mitigations for this, I am currently voting "no" 
> as I am unsure how certain features in Xdebug could remain working. I 
> have written to the list on other reasons before 
> (https://externals.io/message/123277#123450) without a conclusion.
>
> I'll consider changing it to yes if there is a commitment for addressing 
> these feature-maintaining-requirements to keep Xdebug working, either 
> through new APIs (think observer) or other mitigations.
>
> cheers,
> Derick

While I support language and engine cleanup, if this change causes issues for Xdebug that is a fairly significant problem.  For that reason I have shifted my Yes to a No for now.  Like Derick, I will switch it back to a Yes should the Xdebug issue be resolved to his satisfaction.  But "keep Xdebug working" is a rather mission-critical requirement for any RFC, as a practical matter.

--Larry Garfield