Zeev, > The vote on the Coercive Scalar Type Hints is now open for voting. > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > 2. Accept leading/trailing spaces in string->number conversions. > > wiki.php.net/rfc/coercive_sth > wiki.php.net/rfc/coercive_sth#vote > > Thanks! > > Zeev
The proposed coercion rules aren't clear. The first table in the RFC implies that string is accepted for bool hints, and the second table says this is unchanged. But the examples section states that "foo" -> bool will raise an E_DEPRECATED error. I'm guessing this is a mistake, since you mentioned above that string->bool is accepted. You also stated above that false->bool is not supported (I'm guessing you meant float->bool). So users would be able to pass "4.3" to a bool typehint, but not 4.3? This behavior seems very arbitrary and confusing. Not only would this RFC introduce backwards compatibility breaks in a future PHP release, but it still doesn't bring the same opportunities for static analysis which the optional strict mode in Anthony's proposal enables. The coercive RFC misleadingly contradicts itself by stating that "we don't believe that is the case" "that Strict STH can help static analysis in certain cases" "although it's possible that Strict Typing may be able to help static analysis in certain edge cases." Do you believe it will help in certain cases or not? Strict types can absolutely help - not only for static analysis, but also for potential future AOT/JIT development. Why? Because only types need to be checked, rather than values. This is why an optional strict type system in JavaScript makes it possible for Google to make "early and aggressive optimisations" in V8 (see https://developers.google.com/v8/experiments). It also makes it possible to catch errors earlier in development (see the example in my "A different user perspective on scalar type declarations" email). As a developer of large enterprise applications, these benefits are very important to me. > Static Analyzers need to be designed for Languages, rather than Languages > being designed for Static Analyzers. You really have this backwards. Why do you think Facebook created Hack? Why did Microsoft create TypeScript? Why are there serious discussions to add optional strict typing to ECMAScript proper? Theodore Brown -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
