Re: [VOTE] Scalar Type Hints

Hi, > On 7 Feb 2015, at 20:47, Andrea Faulds <ajf@ajf.me> wrote: > >> On 7 Feb 2015, at 10:57, Pavel Kouřil <pajousek@gmail.com> wrote: >> >> I just realized it now (I brought it up in a different manner when >> there was discussion about the RFC), but I didn't notice there was a >> totally false statement about it in the RFC itself. You probably >> should fix it. I'm speaking about the "Strict type checking, which is >> used by many popular programming languages, particularly ones which >> are statically-typed, such as Java, C#, Haskell, or Facebook's Hack. >> It is also used for non-scalar parameter type hints in PHP. With this >> approach, an argument is only accepted if its type is exactly the same >> as the parameter." paragraph. >> >> This is NOT true (at least for C# and Java), as you can read here in >> the documentations of respecitve languages so you should not compare >> the strict version of the typing implemented in PHP with other >> strongly typed languages, because the PHP's "strict" is stricter than >> strongly static typed languages. I really hope noone voted with the >> thought that the strict typing acts as it does in Java and C#. >> >> https://msdn.microsoft.com/en-us/library/y5b434w4.aspx >> >> http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2 > > I don’t think it’s unfair. There’s a limited set of permitted conversions in some > strictly-typed languages, but it’s still strictly-typed. To add to the previous email: * Most of these conversions are between different sizes of the same type (float/double, char/short/int/long, etc.), but this is irrelevant to PHP which has only one size for each type * The other ones are between types (int to float) * Always allowing implicit conversions from float to int is very likely to cause data loss, so it’s not unreasonable for PHP to prevent this specific case * Always allowing implicit conversions from int to float is sometimes going to cause data loss, so it may also be reasonable for PHP to prevent this specific case * Requiring an exact type match has the least mental overhead, and allows types to be checked at compile-time Thanks. -- Andrea Faulds http://ajf.me/