> Isn't this the purpose of Nikic's Saner PHP String comparison RFC? It is, sorry I mixed the discussions here. As I said below, I think that these RFCs would deserved to be merged.
> Because boths nikic's and Andrea's RFC go hand in hand. > And probably if both these RFC get accepted a new "stricter numerical string comparison" RFC could see the light banning leading and trailling whitespace I'd rather tackle the whole thing right now, as PHP 8 is a good opportunity for whatever BC break this will cause. Another such opportunity will not happen again before many years. > Arithmetic in JavaScript cannot be used reliably (in general) without converting your data to the proper type, because 1 + 1 gives you 11 if one of the 1s is encoded as string. PHP does a better job in that respect Sure, PHP has the huge advantage here to have a dedicated string concatenation operator, removing any ambiguity around the + operator. This does not mean that we cannot borrow their semantics for string/number *comparison*! Ben On Wed, 27 Mar 2019 at 15:26, Claude Pache <claude.pa...@gmail.com> wrote: > > > Le 27 mars 2019 à 14:29, Benjamin Morel <benjamin.mo...@gmail.com> a > écrit : > > > > Thinking about this a bit more, what about following JavaScript > semantics? I find them really good in this respect: > > > > Arithmetic in JavaScript cannot be used reliably (in general) without > converting your data to the proper type, because 1 + 1 gives you 11 if one > of the 1s is encoded as string. PHP does a better job in that respect. As a > result, there is good chance that people (it is at least the case for me) > are more confident to rely (often implicitly) on automatic type conversion > between strings and numbers when doing basic arithmetic in PHP than in JS, > including for comparison of numeric values. > > About leading/trailing whitespaces: usually, numbers encoded as strings do > not contain them; so that it may be OK to consider strings containing them > as non-numeric if we want. > > —Claude > >
