[PHP-DEV] [VOTE] Deprecate returning values from __construct() and __destruct()

Mailing Lists php.internals
1

Hi

I just opened the vote on “Deprecate returning values from __construct() and __destruct()”.

RFC: PHP: rfc:deprecate-return-value-from-construct
Discussion: php.internals: [RFC] Deprecate returning values from __construct() and __destruct()

There is a single primary vote to cast. Voting closes 2026-06-29 14:00:00 UTC.

Best regards
Tim Düsterhus

2

On Mon 15 Jun 2026, 15:09 Tim Düsterhus, <tim@bastelstu.be> wrote:

Hi

I just opened the vote on “Deprecate returning values from __construct()
and __destruct()”.

RFC: https://wiki.php.net/rfc/deprecate-return-value-from-construct
Discussion: https://news-web.php.net/php.internals/130808

There is a single primary vote to cast. Voting closes 2026-06-29
14:00:00 UTC.

Best regards
Tim Düsterhus

Just to clarify: return $this->privateVoidReturning(); will also trigger a deprecation?

3

Hi

Am 2026-06-15 15:19, schrieb Kamil Tekiela:

Just to clarify: return $this->privateVoidReturning(); will also trigger a
deprecation?

Yes. This is consistent with `return some_void();` in a function that has an explicit `: void` return type:

     <?php

     function foo(): void {
         return;
     }

     function bar(): void {
         return foo();
     }

see: Online PHP editor | output for 2cQYR

I'll make sure to add a corresponding test case to the implementation for completeness.

Best regards
Tim Düsterhus

4

On Mon, Jun 15, 2026 at 7:11 AM Tim Düsterhus <tim@bastelstu.be> wrote:

Hi

I just opened the vote on “Deprecate returning values from __construct()
and __destruct()”.

RFC: PHP: rfc:deprecate-return-value-from-construct
Discussion: php.internals: [RFC] Deprecate returning values from __construct() and __destruct()

There is a single primary vote to cast. Voting closes 2026-06-29
14:00:00 UTC.

Best regards
Tim Düsterhus

Tim, sorry if I missed it in the discussion and RFC: is there any plan
to allow declaring `function __construct(): void` at the same time?
Since:
1. We are going to actively enforce that they don't return anything,
2. and returning `void` is the correct declaration for such functions
(and I would argue `null` as well but I don't care too much about
this, I debated mentioning it at all because it's a bit off in the
weeds),

doesn't it make sense to also allow declaring a void return at the same time?

5

Hi

On 6/15/26 16:56, Levi Morrison wrote:

Tim, sorry if I missed it in the discussion and RFC: is there any plan
to allow declaring `function __construct(): void` at the same time?
Since:
  1. We are going to actively enforce that they don't return anything,
  2. and returning `void` is the correct declaration for such functions
(and I would argue `null` as well but I don't care too much about
this, I debated mentioning it at all because it's a bit off in the
weeds),

doesn't it make sense to also allow declaring a void return at the same time?

Allowing an explicit `: void` return is not part of the RFC.

I intentionally focused on the deprecation to keep the RFC focused on the “important bits”, namely removing this confusing behavior.

That's also why `__clone()` is intentionally left to future scope, since the situation there is slightly different. It definitely makes sense to me to align `__clone()` with `__construct()` in one way or another, though, since they effectively only differ in s/new/clone/ for their intended use.

Best regards
Tim Düsterhus

6

Hi

Am 2026-06-15 15:09, schrieb Tim Düsterhus:

I just opened the vote on “Deprecate returning values from __construct() and __destruct()”.

RFC: https://wiki.php.net/rfc/deprecate-return-value-from-construct
Discussion: php.internals: [RFC] Deprecate returning values from __construct() and __destruct()

There is a single primary vote to cast. Voting closes 2026-06-29 14:00:00 UTC.

The RFC was accepted unanimously with 39 (Yes) votes and no abstentions.

Best regards
Tim Düsterhus