On Mon, 29 Jun 2020 at 14:53, Claude Pache <claude.pa...@gmail.com> wrote:
> > > Le 29 juin 2020 à 12:30, G. P. B. <george.bany...@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 > The behaviour of explicit casts (or any other conversion which accepts errors in the string, which corresponds to the 1 mode of allow_errors in the relevant C is_numeric_string function) will be preserved, so this should still produce 2. I will add test cases and clarify this in the RFC. Best regards George P. Banyard
