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
By the way, I urge everyone to try out "yield 1" from the BC impact chapter.
That really demonstrates that the current "new" methodology is pointless.
# Problem
The "new" operator internally calls the __construct() function. However,
the return value of the __construct() function is silently lost. This is
very error-prone; I personally made a major security mistake with this when
upgrading from Laravel 9 to Laravel 12.
To prevent future problems, my proposal is to have the "new" operator
explicitly issue warnings, and later have it explicitly abort when the
__construct() function returns a value.
A high-level overview of the "new" operator's operations. I haven't explored
this in detail; it's about the overall picture.
// High level picture of the "new" operator.
$newed = acquire_memory_and_initialize_object()
if (function_exists($newed, '__construct')) {
$newed->__construct(...);
// NOTICE that a return value from the __construct() function is silently
// discarded.
}
return $newed;
# My proposal
Modify the "new" operator to the following. This will prevent a return value
from being silently lost. Instead, a warning will be issued and later the
"new" operator will throw a TypeError.
// High level picture of the adjusted "new" operator.
$newed = acquire_memory_and_initialize_object()
if (function_exists($newed, '__construct')) {
$__constructReturnValue = $newed->__construct(...);
if ($__constructReturnValue !== void) {
// DEPRECATION: returning a value from the __construct() function
// when called by the "new" operator is deprecated.
// LATER: throw new TypeError('the __construct() function must not
// return a value when called by the "new" operator.');
}
}
return $newed;
# BC impact
Yes, there can be BC impact. If the __construct() function is also used as
a regular function. For example,
class SomeTheoreticalExample
{
public $uniqueId;
public function __construct(bool $returnSomeValue)
{
static $uniqueId = 0;
$this->uniqueId = $uniqueId;
$uniqueId++;
if ($returnSomeValue) {
// return some pointless value. Pointless, because it is
// silently discarded by the "new" operator.
return 'abc';
// return 1;
// return 1.23;
// return null;
// return true;
// return false;
// return ['a', 'b', 'c'];
// return [6 => 'six', 7 => 'seven', 67 => 'six seven'];
// return ['a' => 'a', 'b' => 'b', 'c' => 'c', 0 => 'Zero'];
// return SomeEnum::Spades;
// return function() {};
// return fn($a) => $a;
// return new DateTimeImmutable();
// return fopen('php://memory', 'w+');
// return $this;
// return &$this;
// return new SomeTheoreticalExample(false);
// Laravel 12 controller specific, of course this is very
// very wrong. It will NEVER redirect, and the flow
// continues to reach the (unauthorized) controller function.
// return redirect()->route('login');
// This is a very terrible case. Try it out yourself and
// watch the returned $newed->uniqueId.
// Spoiler alert: it won't be 0.
// yield 1;
}
}
}
// Before the RFC TypeError fact: nothing.
// After the RFC fact: will fail.
$newed = new SomeTheoreticalExample(true);
// Before the RFC TypeError fact: nothing.
// After the RFC fact: never called, because of the previous statement failure.
$someReasonToCall__ConstructAgain = $newed->__construct(true);
# RFC
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
( PHP: 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.
I am very very reluctant to follow the RFC process myself:
* It would take up a lot of my free time. I would write the RFC first in
Dutch, my native language, and then translate it into English. This is
because I speak and write English, but don't understand all the nuances
of (American/Australian/British/Canadian/Irish/Nigerian/...) English.
* While I do have some knowledge of C and the php-src codebase, writing a
PR to implement the RFC would take up a significant amount of my
free time.
* The True Async RFC has demonstrated that the author of an RFC must have
a certain degree of trustworthiness. And I, as a passerby, have not
established any trustworthiness.
* The voting process of an RFC is highly uncertain and can lead to
rejection. The whole process could ultimately be a complete waste
of my time.
Anyone who would like to create an RFC for this, please go ahead.
Yours sincerely,
Mirco Babin
