Hi Patrick,
I understand but we cannot include casting rules in the scope. And, while attractive, I think ZPP and casting cannot share the same ruleset, at least as long as casting is defined as aimed to being as permissive as possible. François De : Patrick ALLAERT [mailto:patrickalla...@php.net] Envoyé : jeudi 19 février 2015 13:46 À : franc...@php.net; Sara Golemon; PHP internals Objet : Re: [PHP-DEV] Scalar Type Hints v0.4 Le Wed Feb 18 2015 at 19:10:08, François Laupretre <franc...@php.net> a écrit : > De : Patrick ALLAERT [mailto:patrickalla...@php.net] > > The biggest advantage, IMHO, is that you get the exact same result whether > you do: > > foo((int) $value); > > or: > > foo($value); > > ... whatever the mode you are in. Wrong. Parameter parsing rules are much more restrictive than casting rules. Only 'foo((int)'orange')' would (erroneously) succeed. Francois, I'm very aware of the distinction between cast mechanism and ZPP, but I obviously haven't been clear about the fact that the (conversion|coercion|type juggling|...) reporting configuration I proposed would have to be used in ZPP *AND* casting mechanism (and anywhere else where some conversion applies). With: $value = "foo"; foo((int) $value); it is: "(int) $value" that would generate a warning/error depending on the reporting, not while parsing the parameter of function foo(), which would receive an int (0) in this precise case. And this would address the cases: http://example.org/foo.php?id=42 http://example.org/foo.php?id=bar foo.php: <?php fetchById(int $id) { // ... } fetchById($_GET["id"]); even if $_GET["id"] is replaced by (int) $_GET["id"]; Cheers, Patrick
