Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130109
Precedence: list
MIME-Version: 1.0
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>
 <6412E222-9B0F-4139-A6F9-7D0C686197BF@rwec.co.uk>
In-Reply-To: <6412E222-9B0F-4139-A6F9-7D0C686197BF@rwec.co.uk>
Date: Fri, 20 Feb 2026 17:07:01 +0100
Message-ID: <CAFgk54=S1KjPwgHy_Qy7xtGbVvfHkd4SEMZ+o1WhzaVHZQ7ncw@mail.gmail.com>
Subject: Re: [PHP-DEV] [IDEA for RFC] let the "new" operator fail when the
 __construct() function returns a value.
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
From: mirco.babin@gmail.com (Mirco Babin)

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