Re: [RFC] Saner numeric strings

> Le 29 juin 2020 à 12:30, G. P. B. <george.banyard@gmail.com> a écrit : > > Greetings internal, > > While reviving the "Permit trailing whitespace in numeric strings" RFC [1] > I didn't see Nikita's comment on Andrea's original PR which commented on > the fact that we should get rid of the "leading-numeric string" concept. > > Therefore, mostly due to time constraints, I've merge the trailing > whitespace RFC with the removal of this concept in the following RFC: > https://wiki.php.net/rfc/saner-numeric-strings > > The main gist is to convert all E_NOTICEs “A non well formed numeric value > encountered” to the usual E_WARNING “A non-numeric value encountered” and > allow trailing whitespaces, which would be most reasonables cases where the > E_NOTICE has been emitted. > > This RFC is heavily based on Andrea's original RFC [1] and I would like to > thank her once more for the preliminary work she's done that I could reuse. > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/trailing_whitespace_numerics Hi, It is not clear for me, by reading the RFC, whether or not the behaviour of either implicit or explicit conversion of so-called leading numeric string will be preserved, beyond some Notices that will be converted to Warnings in the implicit case. For example, does (int) "2px" still produce 2, even when the string is now considered as non-numeric? I think it is important to make sure that the current results of casting to int/float will not change. For example, I can imagine some script that reads a CSS value like "2px" and does some calculation on it, converting it to a number on the process. A Warning instead of a Notice will prompt the programmer to add explicit casts, which is probably a good thing. But changing the casted value to 0 would lead to bugs that are (1) harder to detect especially if the program already uses explicit casts, and (2) harder to correct. —Claude