Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130086
Feedback-ID: id5114917:Fastmail
Message-ID: <453bc043-b4ee-423e-9561-55510f5c20a7@rwec.co.uk>
Date: Tue, 17 Feb 2026 19:24:47 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [IDEA for RFC] let the "new" operator fail when the
 __construct() function returns a value.
To: internals@lists.php.net
References: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com>
 <1f25d77e-224b-40d6-bf19-18dfdfc9de54@rwec.co.uk>
 <CAFgk54knVsdNQbVxVL43qyA3vkQrMHZt=ATfuiDCD4qJa6MPVg@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAFgk54knVsdNQbVxVL43qyA3vkQrMHZt=ATfuiDCD4qJa6MPVg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 17/02/2026 06:59, Mirco Babin wrote:
> I disagree with the compiling part. The __construct() function can
> currently not have a return type, so the return type is implicitly
> "mixed". Changing that would be a BC break for those calling the
> __construct() function as a regular function.


It's a BC break either way - which is fine, if it only happens in PHP 9.0.


Consider this example in your draft RFC:

```
class UnaffectedBaseClass
{
     public function __construct()
     {
         return ['important'];
     }
}
```

Right now, there is nothing stopping someone calling that constructor as 
`new UnaffectedBaseClass`. In PHP 9.0, that working code will become an 
error - a BC break.

This is true even if the class is marked `abstract`:

```
abstract class AbstractBaseClass
{
     public function __construct()
     {
         return ['important'];
     }
}

class ValidSubClass extends AbstractBaseClass
{
}

$it = new ValidSubClass(); // Error in PHP 9.0
```


In fact, the only way to guarantee a class is unaffected would be to 
write a method called "__construct", but then use static analysis to 
prove that nothing actually uses that method as a constructor. In which 
case, why use the reserved name "__construct"?


My suggestion is that classes which are affected should show an error 
*as soon as possible*, so that users are prompted to fix the definition.

In the example above, I would much prefer to see the error (or 
deprecation notice) as soon as AbstractBaseClass is compiled, rather 
than waiting for something in the code base to call "new ValidSubClass".

Similarly, if there's a long constructor with a return statement inside 
some rarely used conditional logic, I would prefer to be told 
immediately that there is a mistake, rather than having a production 
error when the rare situation happens.


Once I'm told about the problem, I can choose between two things:

1) Stop the constructor returning a value, e.g. by replacing "return 
foo();" with "foo(); return;"
2) Rename the method to a non-reserved name, and if needed add a new 
constructor which calls the method and discards the result


Thinking that through, having an error thrown only when calling with 
`new` would actually be *more* disruptive. I would probably vote "No" to 
that version of the proposal.

Regards,

-- 
Rowan Tommins
[IMSoP]