Re: [IDEA for RFC] let the "new" operator fail when the __construct() function returns a value.

From: Date: Tue, 17 Feb 2026 07:39:37 +0000
Subject: Re: [IDEA for RFC] let the "new" operator fail when the __construct() function returns a value.
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-130080@lists.php.net to get a copy of this message
>The "Make constructors and destructors return void" RFC was voted on and >declined in 2020. PHP has come a long way since then, and I'm curious >whether a similar proposal (targeting PHP 9) might pass nowadays. I'd >certainly consider voting for it. Perhaps in PHP 8.6, we could begin >emitting a deprecation message for constructors that return values? As written to Tim Düsterhus: I have prepared a RFC at https://gist.github.com/MircoBabin/aaa574297c8d1baa879f19c99ce28e93 Kind regards, Mirco Babin Op wo 4 feb 2026 om 03:30 schreef Ben Ramsey <ramsey@php.net>: > > On 2/2/26 12:00, Mirco Babin wrote: > > # 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. > > Can you elaborate on this? I'd like to better understand what the > problem was with constructors that returned values when you upgraded > 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. > > So, to restate your proposal: you want to disallow returning from > constructors…but only if invoked when using the new keyword? > > So, if you call $object->__construct(), there's no > error, and you can > get the return value, but if you do new Foo(), you'd get > an error? > > > 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. > I'm not sure how this differs from the void return type proposal. When > it throws a TypeError, it will effectively be saying, "this method can't > return anything," which means the return type is void. > > The "Make constructors and destructors return void" RFC was voted on and > declined in 2020. PHP has come a long way since then, and I'm curious > whether a similar proposal (targeting PHP 9) might pass nowadays. I'd > certainly consider voting for it. Perhaps in PHP 8.6, we could begin > emitting a deprecation message for constructors that return values? > > Cheers, > Ben >

« previous php.internals (#130080) next »