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]
