Robert, > you wrote: "aliases are removed (integer and boolean)" > what about the aliases real and double?
They were never part of Andrea's proposal. So they were never accepted anyway. > You wrote: "behaviour of weak type checks: float -> int *Only non-NaN floats > between PHP_INT_MIN and PHP_INT_MAX accepted. (New in PHP 7, see the ZPP > Failure on Overflow RFC)" > What about INF? Can INF be passed or not and if so, how is it converted? Please see the other RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow Namely: The special floating-point values INF and -INF fail the check like any other number that is too large. > Personally I would be stricter and disallow int->bool, float->bool, > string->bool as well as bool -> int, bool -> float and bool -> string (at > least for this RFC) > Why? > 1. I already mentioned the common if(strpos(..)){} case but is something > which none of the RFC addressed so far and probably goes too far (you wrote > "In addition to userland functions, the strict type checking mode also > affects extension and built-in PHP functions:" but control structures are not > affected, right?) This only affects function calls. Not control structures. > 2. It supports an inconsistency in PHP which we should try to get away with > rather than promoting it. Following an example: > > function foo(string $x){ > var_dump($x); > bar($x); > } > function bar(bool $x){ > var_dump($x); > baz($x); > } > function baz(string $x){ > var_dump($x);} > foo(0); > > and the output would be: > > string(1) "0" > bool(false) > string(0) "" > > Sure, removing the implicit conversions from and to bool do not pretend that > the same would happen if one uses manual conversions instead. Yet, IMO we > should forbid the implicit conversion from and to bool now and add it later > on with consistent conversion rules. This way we have more time to think > about a clean solution and adding implicit conversion from and to bool should > also not be a BC break in 7.1 Simple: don't use weak mode. This proposal does not invent the weak mode rules, it simply exposes them from ZPP (how it's implemented in all internal functions) to userland hints. So any change there would be outside of scope for this proposal and should be made as another proposal. I will add this to the discussion points section. > Another example: > > function foo(int $x){ > var_dump($x); > bar($x); > } > function bar(string $x){ > var_dump($x); > } > foo(false); > bar(false); > > and output: > > int(0) > string(1) "0" > string(0) "" > > I think you get the inconsistency I am writing about. > > > About widening. It is not clear from the RFC if widening is only applied for > int -> float or also for bool -> int, bool -> float respectively. It's explicitly stated: "This means that parameters that declare float can also accept int." I will clarify this as well. Thanks! Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
