Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130067
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------3YfQsyazRDN3zlbp8GUt30eg"
Message-ID: <1f25d77e-224b-40d6-bf19-18dfdfc9de54@rwec.co.uk>
Date: Tue, 10 Feb 2026 20:33:15 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [IDEA for RFC] let the "new" operator fail when the
 __construct() function returns a value.
To: internals@lists.php.net
References: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------3YfQsyazRDN3zlbp8GUt30eg
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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]

--------------3YfQsyazRDN3zlbp8GUt30eg
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 02/02/2026 18:00, Mirco Babin wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">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
<a class="moz-txt-link-freetext" href="https://github.com/php/php-src/issues/21090">https://github.com/php/php-src/issues/21090</a></pre>
    </blockquote>
    <p><br>
    </p>
    <p>Hi Miro, and welcome!</p>
    <p>I agree that allowing constructors to return a value leads to
      confusion, and would support deprecating and then forbidding this.</p>
    <p>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".</p>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
cite="mid:CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">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
( <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/make_ctor_ret_void">https://wiki.php.net/rfc/make_ctor_ret_void</a> ) rejects my proposal.
However, my proposal is explicitly about the "new" operator and not
about return types. It does, however, concern return values.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>According to the current policy, it is allowed to "resurrect" a
      failed proposal after just 6 months:
<a class="moz-txt-link-freetext" href="https://github.com/php/policies/blob/main/feature-proposals.rst#resurrecting-rejected-proposals">https://github.com/php/policies/blob/main/feature-proposals.rst#resurrecting-rejected-proposals</a>
      That seems very short to me, but in this case it has been nearly 6
      *years*.</p>
    <p>I would also note that the RFC only narrowly failed - it received
      60% Yes votes, but failed to meet the threshold of two-thirds.</p>
    <p>You can see the discussion and voting threads for that previous
      RFC here: <a class="moz-txt-link-freetext" href="https://externals.io/message/110612">https://externals.io/message/110612</a>
      and <a class="moz-txt-link-freetext" href="https://externals.io/message/110824">https://externals.io/message/110824</a></p>
    <p>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:</p>
    <p>- In PHP 8.next, raise a Deprecation at compile-time if a method
      named "__construct" returns a value<br>
      - In PHP 9.0, throw an Error instead</p>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
cite="mid:CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">I am very very reluctant to follow the RFC process myself</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I would like to echo everything Tim said on this, and encourage
      you to start the RFC.</p>
    <p> If you look down the list of accepted RFCs at
      <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc">https://wiki.php.net/rfc</a> 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.</p>
    <p><br>
    </p>
    <p>Regards,</p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------3YfQsyazRDN3zlbp8GUt30eg--