Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130101
Feedback-ID: id5114917:Fastmail
Date: Fri, 20 Feb 2026 07:40:14 +0000
To: internals@lists.php.net
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BIDEA_for_RF?=
 =?US-ASCII?Q?C=5D_let_the_=22new=22_operator_?=
 =?US-ASCII?Q?fail_when_the_=5F=5Fconstruct=28?=
 =?US-ASCII?Q?=29_function_returns_a_value=2E?=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFgk54kmk8uYjF8RcsOGKAyvBZNn2tYEd9D1PVK2prfeU=pF5A@mail.gmail.com>
References: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com> <1f25d77e-224b-40d6-bf19-18dfdfc9de54@rwec.co.uk> <CAFgk54knVsdNQbVxVL43qyA3vkQrMHZt=ATfuiDCD4qJa6MPVg@mail.gmail.com> <453bc043-b4ee-423e-9561-55510f5c20a7@rwec.co.uk> <CAFgk54nimvF4UC6KOxaGg-v5hFazt1sNTyyJ-bkqHy6Xm5nOHA@mail.gmail.com> <e4d2994a-ae1e-4f33-89c3-67c5df99f1d3@rwec.co.uk> <CAFgk54kmk8uYjF8RcsOGKAyvBZNn2tYEd9D1PVK2prfeU=pF5A@mail.gmail.com>
Message-ID: <6412E222-9B0F-4139-A6F9-7D0C686197BF@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 19 February 2026 20:24:56 GMT, Mirco Babin <mirco=2Ebabin@gmail=2Ecom> w=
rote:
>> That's a different kind of "why"=2E I meant, "why would a programmer
>> deliberately call a function __construct, and have no intention of
>> *ever* using it as a constructor"=2E
>
>A theoretical example can be found in
>"Unaffected calling the parent constructor example"=2E
>UnaffectedBaseClass could be abstract=2E
>
>```php
>class UnaffectedBaseClass
>{
>    public function __construct()
>    {
>        return ['important'];
>    }
>}
>
>class UnaffectedCallParentConstructor extends UnaffectedBaseClass
>{
>    public function __construct()
>    {
>        $important =3D parent::__construct();
>    }
>}
>
>$it =3D new UnaffectedCallParentConstructor();
>```


In that example, the method on UnaffectedBaseClass can not be used as a co=
nstructor under your proposal=2E As such, it's just a normal method which c=
an be trivially renamed:=20

```
class UnaffectedBaseClass
{
    public function initialise()
    {
        return ['important'];
    }
}

class UnaffectedCallParentConstructor extends UnaffectedBaseClass
{
    public function __construct()
    {
        $important =3D parent::initialise();
    }
}

$it =3D 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=2E
>
>Not necessarily=2E When an if is used, __construct() can be either=2E


True=2E I'm not convinced the language should bend over backwards to suppo=
rt such a pattern, though=2E



>The Php scripting aspect makes it difficult in general
>for untyped projects to fail early=2E=20


This is a completely irrelevant statement=2E We're not talking about faili=
ng early "in general", we're talking about a compile-time check that PHP al=
ready makes in other contexts=2E



>> 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=2E
>
>Not necessarily true=2E Assume the code is running fine on a shared hosti=
ng
>platform with Php 8=2E5=2E Then the hosting provider decides to force an
>update to Php 9, because of a critical vulnerability=2E That same code
>would then break at some point=2E=20


I don't see how this contradicts what I said=2E Instead of it failing imme=
diately, it fails "at some point" - so, it will take longer to happen=2E Yo=
u consider that a good thing, I consider it a bad thing; I guess we're not =
going to convince each other on that=2E


>I assume the spaghetti contains some version of my two theoretical
>examples=2E
>
>So it is safer to *not* make the return type declaration implicitly "void=
"=2E


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 u=
sers to fix=2E There are three options on the table:=20

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 us=
es of the "new" operator reach that return statement


I find option 3 unnecessarily complicated=2E Faced with an existing code b=
ase, checking and fixing violations of option 2 seems a lot easier than kee=
ping the return values but making sure they won't error under option 3=2E

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=2E


Regards,

Rowan Tommins
[IMSoP]