Op vr 20 feb 2026 om 08:43 schreef Rowan Tommins [IMSoP] <[email protected]>:
>
> On 19 February 2026 20:24:56 GMT, Mirco Babin <[email protected]> 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
