Re: [IDEA for RFC] let the "new" operator fail when the __construct() function returns a value.

On 02/02/2026 18:00, Mirco Babin wrote:

Subject: [IDEA for RFC] let the "new" operator fail when the __construct() function returns a value. Date: 2 february 2026, 19:00h (Europe/Amsterdam) Hello Internals, The starting point of this idea is https://github.com/php/php-src/issues/21090

Hi Miro, and welcome! I agree that allowing constructors to return a value leads to confusion, and would support deprecating and then forbidding this. However, I agree with others that this should be checked when compiling the constructor, not when running it under the "new" operator. In other words, make any method named "__construct" give the same error as a function or method marked ": void".

I've been asked to follow the RFC process. And I've been told that the rejected PHP RFC Make constructors and destructors return void (https://wiki.php.net/rfc/make_ctor_ret_void ) rejects my proposal. However, my proposal is explicitly about the "new" operator and not about return types. It does, however, concern return values.

According to the current policy, it is allowed to "resurrect" a failed proposal after just 6 months: https://github.com/php/policies/blob/main/feature-proposals.rst#resurrecting-rejected-proposals That seems very short to me, but in this case it has been nearly 6 *years*. I would also note that the RFC only narrowly failed - it received 60% Yes votes, but failed to meet the threshold of two-thirds. You can see the discussion and voting threads for that previous RFC here: https://externals.io/message/110612 and https://externals.io/message/110824 It looks like there was a lot of discussion around the exact timeline, and whether to allow an explicit ": void". A new RFC could focus on *only* the "void-like behaviour", and set out a clear timeline. In other words: - In PHP 8.next, raise a Deprecation at compile-time if a method named "__construct" returns a value - In PHP 9.0, throw an Error instead

I am very very reluctant to follow the RFC process myself

I would like to echo everything Tim said on this, and encourage you to start the RFC. If you look down the list of accepted RFCs at https://wiki.php.net/rfc you will see that some are long discussions of complex features; but others are just a few paragraphs. The way you laid out your e-mail already has most of what's needed: state the Problem, detail the Proposal, and assess the Impact. Regards, -- Rowan Tommins [IMSoP]