Hi Pavel, > On 25 Jan 2015, at 08:38, Pavel Kouřil <pajou...@gmail.com> wrote: > > personally I still don't like this RFC in it's current form and > "shorter" declare won't change it.
I didn’t expect that making it shorter would really change anyone’s opinions, except perhaps those who don’t like the term “type hint”. > I was thinking a lot about the > typehints in PHP for last few days and I think having only one way > would be the best - and it's somewhere between the curent weak and > strict typing. My main "issue" is that the current weak typing is too > loose and the strict typing is too strict. > > The problem with the current strict typing is that you cannot pass > "int" to a "float" parameter, even though there can be a totally > lossless conversion and it works in other strongly typed languages. It can *sometimes* be a lossless conversion. Only sometimes. For float to int conversion: * Floats have the special values INF, NAN and -NAN, which cannot be preserved * Floats have negative zero, which also cannot be preserved * Fractional components cannot be preserved * Floats sacrifice precision to allow a wider range of values. They work with significant figures (scientific notation), unlike integers which always offer full precision. So a particular float value isn’t necessarily equivalent to a particular integer value, you have to invent precision to do the conversion. 2e10 is dealt with as if it’s 2 with 10 zeroes after it, but it’s just a number beginning with 2 that has a magnitude of roughly 10^10. If you convert it to the integer value 20 000 000 000, you’ve just invented values for those trailing digits - those digits weren’t necessarily zero, we just don’t know what those digits are. Someone who’s an expert on floating-point might need to correct me here, but I think this is correct to some extent. What I’m saying is that float->integer conversion is inherently imprecise. For int to float conversion: * Values beyond 2^53 or below -2^53 cannot be represented as floats without a loss of precision Some strongly-typed languages allow these conversions implicitly, but I’m not sure that’s a good thing or something we should want to copy. Loss of precision isn’t good. If you ask for strict typing, you probably want to avoid it, and should get strict typing. > And being able to pass a float(1.5) to int and lose the 0.5 value > doesn't make sense as well, because data will get lost. Neither of > those feels somehow "predictable" and "natural”. Sure, but it is our existing behaviour. > Also, after a little bit of thinking, if someone needs to do a type > conversion while calling a method, writing foo((int) $bar) isn't that > hard. This isn’t a good idea. Explicit casts do not care for what value you give them, they will convert whether or not the conversion makes sense. Unfortunately we don’t have safe casting functions because they were rejected. Alas. > So, I think it would be best to choose just one of these two > approaches and either loosen it a little or make it more strict (so > data loss doesn't happen). But I guess this approach would be > inconsistent with how the built-in PHP functions work? While it never went to a vote, the Scalar Type Hinting with Casts RFC, which proposed stricter weak casts, was not well-received. The Safe Casting Functions RFC was rejected when it went to a vote. > PS: Ideally, the data loss rules should be made for types and not > values (like the old scalar type hints RFC had), so you don't get > unpredictable results. The Scalar Type Hinting with Casts RFC didn’t do that, it was also based on values. In a dynamically-typed language like PHP, I don’t see why it needs to be type-based rather than value-based. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
