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

Op vr 20 feb 2026 om 08:43 schreef Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>: > > On 19 February 2026 20:24:56 GMT, Mirco Babin <mirco.babin@gmail.com> wrote: > > > >The Php scripting aspect makes it difficult in general > >for untyped projects to fail early. > > > This is a completely irrelevant statement. We're not talking about > failing early "in general", we're talking about a compile-time check > that PHP already makes in other contexts. Failing early is not always possible. The compiler can not always infere the correct return type. E.g. this example will succeed to compile: ```php class UnableToInfereReturnType { private function TruelyUnknown() : mixed { $a = time(); if ($a % 2 === 0) { return ['important']; } } private function ActAsVoid() : void { return $this->TruelyUnknown(); } // Lets act as if the return type is implicitly void public function __construct() // : void { return $this->ActAsVoid(); } } $it = new UnableToInfereReturnType(); // Runtime error, not a compile error. // Fatal error: A void method must not return a value in /in/MJCjX on line 15 ``` Even in a project where each and every function has a return type declaration, even all packages in the "vendor" directory have a return type declaration, there are still cases where compilation will succeed and a TypeError will be thrown at runtime. In an untyped project compilation will *always* succeed, because all return types are implicitly mixed. And the compiler can do nothing with mixed return types. In an untyped project it will always be a TypeError at runtime. Fail early is very subjective. > >I assume the spaghetti contains some version of my two theoretical > >examples. > > > >So it is safer to *not* make the return type declaration implicitly > >"void". > > > The way I see it, we have to draw the line somewhere regarding what > use of "__construct" methods is "acceptable", and what use we're going > to force users to fix. There are three options on the table: > > 1) You may return any value, the "new" operator will silently discard it [current behaviour] > 2) You must not return a value > 3) You may return a value in the definition, but > must make sure that no uses of the "new" operator > reach that return statement > > > I find option 3 unnecessarily complicated. Faced with an existing code > base, checking and fixing violations of option 2 seems a lot easier > than keeping the return values but making sure they won't error under option 3. > > I think that either we should add a simple, easily checked, rule - option 2; > or we should avoid breaking people's code, and retain option 1. Thank you for your input so far. I have decided to move forward to the official discussion phase. Kind regards, Mirco Babin