> 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're right - that was an oversight when I updated the string->bool and int->bool. Removed. Thanks! > 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. It may be confusing, but only academically so. Again, this approach tries to work well with real world usage - and reject conversions which are likely to be erroneous. "4.3" may look like a floating point number but in the context of conversion to boolean, that doesn't matter much. It's a string. > 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? I don't believe strict STH would bring any meaningful gains for static analysis, no. Unlike the JIT/AOT advantages (on the same code) which I believe I've proven cannot be gained, I can't prove this one - because you can infer slightly different data from strict type hints. But again, in edge cases. Such as: function bar(float $x) $foo = 1; bar($foo); // will definitely fail in strict mode Does it give you much? Not really. > 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. I'm sorry, but that is simply wrong. Why? Because types ARE in fact a part of the value in PHP. They're an element of PHP's value structure (zval). You do NOT know the value with certainty until runtime, because again, the type IS in fact a part of the value. The very same type inference you can do with strict types you can do with coercive or even with weak types. Again, this has been discussed in length in the threads that took place several weeks ago. I believe even Anthony concluded that for a given piece of code - assuming it's unchanged - there are no AOT/JIT advantages. The theory is that there can be stronger static analysis, which will provide more insightful suggestions to the developer to change their code which will in turn result in code that can be JIT'd or AOT'd better. Here too, we don't believe that's the case and believe you can provide the same value with coercive type hints. 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. I'm not saying that type hints don't make compile-time type inference easier or more powerful. I am saying there's zero difference between coercive type hints and strict type hints (and, also, that given we only know the types with certainty right after the entry point to the function, it gives you a lot less value than you might think - in both cases). Please do see the lengthy threads we had on this subject a few weeks ago. > > > 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? I hardly think that static analyzers were the key reason for that at all, but either way, that's my opinion. Again, note that I'm not arguing there's zero advantage gained from adding type information to code - from both reliability and performance perspectives. I am saying there's zero difference on whether we coerce or error out in case we get a certain value. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
