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

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: https://3v4l.org/2cQYR#v

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

Best regards
Tim Düsterhus

Hi

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