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:
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 statementI 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