Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104965 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69900 invoked from network); 27 Mar 2019 17:04:22 -0000 Received: from unknown (HELO mail-ua1-f41.google.com) (209.85.222.41) by pb1.pair.com with SMTP; 27 Mar 2019 17:04:22 -0000 Received: by mail-ua1-f41.google.com with SMTP id d5so252597uan.6 for ; Wed, 27 Mar 2019 06:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F0RO7jAUKZlhKmTSAMcLSL6w3QO5tEG2BCIeNMpZ8VI=; b=hcixApjMMB3inRw+U1nTRI85yZDG51dVLN5lT7UaWBOfSSMAgtTdyASrWRu6dckNjC lUCR3TTKKnJtbkGvJJ1oeBiP2B5Fbn8C/RZvOS4IQbcaeYJbm8GAGIjVVeA5IzfakMeW tppOOghllJ6WBWmyIZkRxTHS2jbuWR0RKo1pZHRd42TZ1mqGQRMW8fgc7FtPFsEVefpv k3gwBg7ncdbYq7LfOunxfn5NThHXcZ99m71EmMzU2V/9Z7RJ8GM04jMUujZzWyOt1SNE eWRs70DQcfsHsPEsDCoC/kMXDz0vuJ64JwNvWtkGZGGX1lAFlUK3CAwgHqtm8l3Pccvl gD+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F0RO7jAUKZlhKmTSAMcLSL6w3QO5tEG2BCIeNMpZ8VI=; b=kSvKVnR40r+um6cdojtcm/ijvBFGXVlybbKqdXMQeIimvLaEvl4VGLHRPl2PwyEhXF zLOTcQ1hotjAv73LLyAcGcg5dHXI2WqY2vjPOP3Mu993uDGJVE+sjcjh47/C4mOx1O1u wY6Dw5kzUSExdrpoVm8SfUL0L+YjGpoXlDJuL7kOdCx0KY80dwG0wHDRk3zSCzJUIOFa 1NeKH2ocZGI5oqi6lezEuxelyDW8fURWDrrY0S2XK4Owj9O8twhyvPZzd3FVOzrvTo/V 6k60JKpLqj9uHRKHd45ohaWiLqU1afZVleZ+OlFFjpe/yVZS8EfjD7XfCcBbInmRSZAp YCxQ== X-Gm-Message-State: APjAAAUhx48bxkicckMxdnL/wP9gYvTHXm7nHJ51R8iCmVFHI8wCucyL lDw1Kth7aasz5HHeHqXw6nNDIeSHOlOlpOgifSk= X-Google-Smtp-Source: APXvYqzOaHAv803gyHmj8rPNPB4OHN4uZu1aZvbfriF6OSyTWXoSZG76sxVPKwUxn4RyUqHJX7XCx0CslcPlJ+G1q7g= X-Received: by 2002:ab0:3314:: with SMTP id r20mr10720455uao.69.1553695080661; Wed, 27 Mar 2019 06:58:00 -0700 (PDT) MIME-Version: 1.0 References: <6C077569-A049-422B-A4CD-6EE5F8DEC388@gmail.com> In-Reply-To: Date: Wed, 27 Mar 2019 14:57:49 +0100 Message-ID: To: Benjamin Morel Cc: Claude Pache , Rowan Collins , PHP Internals Content-Type: multipart/alternative; boundary="0000000000005f4971058513d32f" Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings From: george.banyard@gmail.com ("G. P. B.") --0000000000005f4971058513d32f Content-Type: text/plain; charset="UTF-8" On Wed, 27 Mar 2019 at 14:30, Benjamin Morel wrote: > > It is a well-known feature that you can work with such data without > previously converting it explicitly to some number type. > > I'm not requesting to change this: if you're doing string("3.5") + int(7), > you should still get float(10.5). What I'm suggesting we change, is > comparison of numbers and decimal strings. > > Thinking about this a bit more, what about following JavaScript semantics? > I find them really good in this respect: > > - when comparing two strings, always use strcmp(): > > var_dump("42" == "42.0"); // false > var_dump("3" < "23"); // false > > - when comparing a number with a string, cast the string to a number, then > compare: > > var_dump(3 < "23"); // true > var_dump("3" < 23); // true > var_dump(42 == "42"); // true > var_dump(42.0 == "42"); // true > var_dump(42.5 == "42.5"); // true > var_dump(42 == "42.0"); // true > > - if the string does not represent a valid number, always return false: > > var_dump(42 == "42x"); // false > var_dump(42 == "x42"); // false > var_dump(1 >= "abc"); // false > var_dump(1 < "abc"); // false > > Note: JavaScript actually allows leading & trailing whitespace around the > number: > > var_dump(42 == " 42 "); // true > > On this last point, I'm not sure whether we should allow both leading & > trailing whitespace, or disallow both of them. > Other than that, I love the way they handle implicit conversions here. It's > so much more understandable, easy to remember, and less prone to errors > IMO. > > Ben > Isn't this the purpose of Nikic's Saner PHP String comparison RFC? And in the discussion of this RFC the discussion of accepting trailings whitespaces came into play. As most people agree with changing it however trailling and leading spaces should have the same behavior. IMHO I think we should accept traillings spaces to make it more consistant (and have a smaller BC break) than banning leading and traillings spaces. 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 whitespaces. Just my two cents. Best regards George P. Banyard --0000000000005f4971058513d32f--