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]
