On 18/02/2026 15:23, Mirco Babin wrote:
In fact, the only way to guarantee a class is unaffected would be to
write a method called "__construct", but then use static analysis to
prove that nothing actually uses that method as a constructor.
At the moment, without changing anything to Php, PHP Code Sniffer static
analysis is the only option. Would this RFC be accepted, there are at
least additional deprecation notices. But to be sure upfront, you still
would have to use PHP Code Sniffer.
The deprecation notices will tell you about code that *is* affected, but
they can't prove that code is *not* affected, if they only happen at
run-time.
In which
case, why use the reserved name "__construct"?
I'd go one step further. Why can "__construct" be called as a regular
function? Why not prohibit that and make it a truly magical function?
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".
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.
My suggestion is that classes which are affected should show an error
*as soon as possible*, so that users are prompted to fix the definition.
That's a personal preference.
Yes and no. Detecting problems early is widely recognised as reducing
the cost and risks of a project. See for instance discussion around the
term "shift left".
Once I'm told about the problem, I can choose between two things:
1) Stop the constructor returning a value, e.g. by replacing "return
foo();" with "foo(); return;"
2) Rename the method to a non-reserved name, and if needed add a new
constructor which calls the method and discards the result
There is a 3rd option:
if ($calledAsRegularFunction_and_not_as_constructor) {
return foo();
}
Can you point to any real-life example of this?
It feels like a lot of this discussion of BC breaks is assuming that
there's some common code pattern relying on the current behaviour, but
the only examples I've seen so far are of why it would be *wrong* to
return a value.
There are two conflicting goals in the prologue: "Maximum warning"
and "Minimal BC impact". You prioritize Maximum warning. I prioritize
Minimal BC impact.
I disagree that your proposal has a lower BC impact.
The majority of code that currently relies on a constructor returning a
value *will break under both versions of the proposal*. 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.
Your points are correct, from the perspective of a new PHP project.
However, reasoning from the perspective of a very old PHP project,
every BC break is one too many.
It is exactly those old PHP projects that I'm worried about. The ones
that have poor testing coverage, large amounts of spaghetti code, and
will cause some poor engineer to have a 2am alarm because someone the
other side of the world just crashed the application with a run-time error.
--
Rowan Tommins
[IMSoP]
