Repository navigation
Use better error message for non-numeric strings in implicit contexts #20632
Description
Description
When a "non-numeric" string is coerced to an integer or float, PHP raises an error rather than proceeding with the implicit cast. This is a good thing.
However, the error message implies that any string would be invalid, rather than that the content of the string is the problem.
Additionally, a common cause in my experience is that the string is empty, for instance, missing from some input data. It would be helpful for debugging to highlight when this is the case.
Proposal
When coercion to a numeric, float, or int context fails:
- If the string being coerced is empty, use "empty string" as a pseudo-type in the error message
- Otherwise, use "non-numeric string" as a pseudo-type in the error message
Current Behaviour
Mathematical operators:
echo 1 + "1";
// 2
echo 1 + "hello";
// TypeError: Unsupported operand types: int + string
echo 1 + "";
// TypeError: Unsupported operand types: int + stringFunction calls in coercive-call mode:
declare(strict_types=0);
function foo(int $a) { echo $a; }
foo("1");
// 1
foo("a");
// TypeError: foo(): Argument #1 ($a) must be of type int, string given
foo("");
// TypeError: foo(): Argument #1 ($a) must be of type int, string givenProposed behaviour
Mathematical operators:
echo 1 + "1";
// 2
echo 1 + "hello";
// TypeError: Unsupported operand types: int + non-numeric string
echo 1 + "";
// TypeError: Unsupported operand types: int + empty stringFunction calls in coercive-call mode:
declare(strict_types=0);
function foo(int $a) { echo $a; }
foo("1");
// 1
foo("a");
// TypeError: foo(): Argument #1 ($a) must be of type int, non-numeric string given
foo("");
// TypeError: foo(): Argument #1 ($a) must be of type int, empty string given
Activity
iluuu1994 commentedon Dec 3, 2025
Also worth noting that we already have some error messages that include truncated user strings: https://3v4l.org/JS32G#v8.5.0 Maybe that would make things even clearer.
IMSoP commentedon Dec 3, 2025
Ah, nice; I was worried about non-printables, but that seems to have been handled: https://3v4l.org/61dhi#v8.5.0
I think including the "non-numeric" (or similar) is still important, to avoid people assuming that any string would be a problem, so maybe:
That would be really handy for debugging something like
$price = '£20'; ... $total = $price * $quantity;mvorisek commentedon Dec 3, 2025
I support
non-numeric-string(and possiblyempty-string) as the "truncated user string" might be not enough and also it is available in backtrace.Improve TypeError messages for non-numeric/empty strings in coercions
Update: Unit Test to php#20632
Update: Unit Test to php#20632
Update: Unit Test to php#20632
Update: Unit Test to php#20632
Update: Unit Test to php#20632
Update: Unit Test to php#20632
Update: Unit Test to php#20632
rizwan3d commentedon Dec 4, 2025
Hi @iluuu1994,
could you please review this change when you have a moment? Thanks! 🙏
Update: Unit Test to php#20632
Update: Unit Test to php#20632