On 19 February 2026 20:24:56 GMT, Mirco Babin <[email protected]> wrote:
>> That's a different kind of "why". I meant, "why would a programmer
>> deliberately call a function __construct, and have no intention of
>> *ever* using it as a constructor".
>
>A theoretical example can be found in
>"Unaffected calling the parent constructor example".
>UnaffectedBaseClass could be abstract.
>
>```php
>class UnaffectedBaseClass
>{
> public function __construct()
> {
> return ['important'];
> }
>}
>
>class UnaffectedCallParentConstructor extends UnaffectedBaseClass
>{
> public function __construct()
> {
> $important = parent::__construct();
> }
>}
>
>$it = new UnaffectedCallParentConstructor();
>```
In that example, the method on UnaffectedBaseClass can not be used as a
constructor under your proposal. As such, it's just a normal method which can
be trivially renamed:
```
class UnaffectedBaseClass
{
public function initialise()
{
return ['important'];
}
}
class UnaffectedCallParentConstructor extends UnaffectedBaseClass
{
public function __construct()
{
$important = parent::initialise();
}
}
$it = new UnaffectedCallParentConstructor();
```
>> If they are using it as *both* a constructor and a normal method,
>> *their code will break with your proposal* because at some point
>> they will call it as a constructor and hit the new error.
>
>Not necessarily. When an if is used, __construct() can be either.
True. I'm not convinced the language should bend over backwards to support such
a pattern, though.
>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.
>> The only difference that delaying the error to run-time makes, is that
>> it will take longer for people to notice that it is broken.
>
>Not necessarily true. Assume the code is running fine on a shared hosting
>platform with Php 8.5. Then the hosting provider decides to force an
>update to Php 9, because of a critical vulnerability. That same code
>would then break at some point.
I don't see how this contradicts what I said. Instead of it failing
immediately, it fails "at some point" - so, it will take longer to happen. You
consider that a good thing, I consider it a bad thing; I guess we're not going
to convince each other on that.
>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.
Regards,
Rowan Tommins
[IMSoP]
