Re: Coercive Scalar Type Hints RFC

On Sun, Feb 22, 2015 at 9:42 PM, Robert Stoll <php@tutteli.ch> wrote: > > Probably it is a philosophical question how to look at it. IMO the only difference in C# (as > well as in Java) lies in the way the conversions are applied. Implicit conversions are applied > automatically by the compiler where explicit conversions are applied by the user. The difference > lies in the fact that C# is statically typed and implicit conversions are only applied when it is > certainly safe to apply one. However, Implicit conversions in C# behave the same as explicit > conversion since implicit conversion which fail simply do not exist (there is no implicit conversion > from double to int for instance). That is the way I look at it. You probably look at it from another > point of view and would claim an implicit conversion from double to int in C# exists but just fails > all the time => ergo implicit and explicit are different (that is my interpretation of your > statement above). In this sense I would agree. But even when you think in this terms then you have > to admit, they are fundamentally different in the way that implicit conversion which are different > than explicit conversion always fail, in all cases - pretty much as if they do not exist. There are > no cases, neither in C# nor in Java which I am aware of, where an implicit cast succeeds in certain > cases but not in all and an explicit conversion succeeds in at least more cases than the implicit > conversion. Hence, something like "a" should also not work in an explicit conversion in > PHP IMO if it is not supported by the implicit conversion (otherwise strict mode is useless btw.) > > Try out the following C# code: > dynamic d1 = 1.0; > int d = d1; > You will get the error "Cannot implicitly convert type > double to int" at runtime. > > We see a fundamental difference between C# and PHP here. PHP is dynamically typed an relies on > values rather than types (in contrast to C#). Therefore, the above code emits a runtime error even > though the data could be converted to int without precision loss. > This shall be different in PHP according to this RFC and I think that is perfectly fine. Yet, > even more important it seems to me that implicit/explicit conversions behave the same way. > At first it might seem strange to have just one conversion rule set in PHP since PHP is not > known to be a language which shines due to its consistency... > OK, I am serious again. If you think about it from the following point of view: A user writes > an explicit conversion in order to state explicitly that some value will be converted (this is > something which will be necessary in a strict mode). Why should this explicit conversion be > different from the implicit one? There should not be any difference between explicit knowledge and > implicit one. That is my opinion. If you really do not care about data loss and just want to squeeze > a float/string into an int no matter what the value really is then you can use the @ in conjunction > with ?? and provide the desired default value to fall back on if the conversion fails. If > conversions like "a" to int really matters that much to the users of PHP then we could > keep the oldSchoolIntConversion function (as propose in my first email) even in PHP 10 (I would > probably get rid of them at some point). > > Cheers, > Robert > Well, I look at it this way (in a simplified manner). Hopefully this will make you understand my point of view more. - Implicit conversions work only when you are sure you won't lose stuff - Explicit conversions are for forcing (casting) variable to become another type, and when you are explicitely as user calling it, you are aware you can lose values Sure, the literal meaning in C# and PHP differs a little bit (because of static and dynamic typed language differences and stuff), but the *intent* is IMHO the same; implicit conversions can happen in the "background" safely, while for "dangerous" conversions, you have to cast by hand. And I see use cases for both of these types of conversions. Also, you are assuming that there will be a "strict" mode; I sincerely hope there won't. Ssince introduction of "2 modes", I was always saying that there should be only one mode - I don't really care whether it would be strict or weak, but just only one. Regards Pavel Kouril