On Wed, Mar 6, 2019 at 7:41 AM Markus Fischer <mar...@fischer.name> wrote:
> Hello, > > On 06.03.19 01:16, Andrea Faulds wrote: > > https://wiki.php.net/rfc/trailing_whitespace_numerics > > > > I expect this should be an uncontroversial proposal, but maybe I'm > > jinxing it there. I hope you all like it. :) > > > > Thanks to Nikita for reminding me it existed and thus motivating me to > > pick it up again. Also thanks to Nikita for suggesting a potential > > follow-up RFC, and also making the “Saner string to number comparisons” > > RFC, both providing additional impetus for me to finally clean this up > > and put it to discussion. > > Hmm, my first reaction would be the opposite. > > For all the changes which happened during the years, PHP got stricter; > this would make it more lax. > > I know this is totally not the goal of the RFC, by my feeling is if we > would change something (ignoring BC break for a sec) that it would be to > actually _remove_ support for leading whitespace 🤷♀️ > > - Markus > I'm always a fan of making things stricter, but think that in this particular case there are some additional considerations we should keep in mind. 1. What is more important to me here than strictness is consistency. Either both " 123" and "123 " are numeric, or neither are. Making "123 " numeric is a change we can easily do, because it makes the numeric string definition more permissive and is thus mostly backwards compatible. Doing the reverse change is certainly not compatible and will be a much harder sell. 2. I believe that a large part of the motivation here is that by making the numeric string definition slightly more lax (in a consistent manner), we can make *other* things more strict, because this essentially eliminates the only "somewhat reasonable" case of trailing characters. The RFC already mentions two of them: a) We can hard reject "123foo" inputs to "int" arguments (and some other places). Currently this is allowed with a notice. I think if we resolve the trailing whitespace question, then there cannot be any reasonable opposition to this change. b) My own RFC on number to string comparisons would benefit from this. From initial testing it has surprisingly little impact, but one of the few cases that turned up was this comparison with a string that had trailing whitespace. Personally I think both of those changes are a lot more valuable than a stricter numeric string definition without leading/trailing whitespace. Regards, Nikita
