Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111045 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 13323 invoked from network); 16 Jul 2020 15:25:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jul 2020 15:25:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6F93D1804D2 for ; Thu, 16 Jul 2020 07:18:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 16 Jul 2020 07:18:27 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id by13so4862401edb.11 for ; Thu, 16 Jul 2020 07:18:26 -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=XnJXtnxCkQuNKcr3LpuB3I1LcneNjZphYy4Fz6knCcU=; b=rMpwCjVLnYL7Flxa3akz4DWg3qDEUdkOBy5pdMHbUhm0+VZkFCg23G6hds8SScD76P JP+8aZ6FBfrIjwji69xyPa7xsCkbMK3fCveSPwhsnrIc1HHUS7y1L+Dz8kbKte/d3fOW Sj64BK2ysSdTv+er3SEBd1hK78Z0mIcoZ3JyyBmHpKdujaIExNVH5AdODUfvLb+13xT9 9YKjjs7cVMX/idg0GsrrCT4l89mgDIcnw9qu+AkqFsfvDYp1UBHi3AW/eaq2rymc/Urv WOTpjatuS1DBmiV0NEhSnzWlw6ehw64StoCnyFFhMkE27o2p+lfBvBKrqrWwhVk8nb7c 9+Lg== 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=XnJXtnxCkQuNKcr3LpuB3I1LcneNjZphYy4Fz6knCcU=; b=kjulS6C+Oumd/fucTFUCK+znIKipzNf6Ep1XdIhoJmaatgGDXb/bESYkSrczPI1IsS 1iQzROrJa8y6NYYYk7xgqx3omL4kUveB+4n5fl2IqyMz8OCk49slKVRMoC5BJhnNm2sc I0sJZMcLytt8+EudSPrWB7O8oIWmyxDbbtZs7NkBlIIGZclKE7ptnJuWvThQz7iJBZSb 5rBH9twGGXYx30f6mcIErfEcyfjT9nolFoLesajAHAmuftnILnkLg+o3qrBR7fZvGZJn jEDWkrCmmfNJWYXB/qxV77LYeaUWM6fK5FyePgXb2+1yOpX9NJJcTfg83GAXn51TZmO7 p6Nw== X-Gm-Message-State: AOAM533DKIWaiBDrw4OJ/m+3/E/5radsA0lzgpsdsFEAQhG6yPvhpKNf DjhgHVHgc2UArBvY4T/FJEDFn9UNEuYG0FSEuhs= X-Google-Smtp-Source: ABdhPJy1pn/RYhGsp4Jv+q3oKHSML4UImrkH5q57pybHa3zgI9j5vMxmmK0Nr5Amekl6rTAGksWpLz+hjEfMlnTW5Hw= X-Received: by 2002:a05:6402:c82:: with SMTP id cm2mr4891219edb.293.1594909103599; Thu, 16 Jul 2020 07:18:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 16 Jul 2020 17:15:33 +0200 Message-ID: To: Marco Pivetta Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000091b55705aa8fb691" Subject: Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings From: george.banyard@gmail.com ("G. P. B.") --00000000000091b55705aa8fb691 Content-Type: text/plain; charset="UTF-8" On Thu, 16 Jul 2020 at 15:39, Marco Pivetta wrote: > Hey George, > > I really like this specific bit of the proposal: > > > And the various cases which currently emit an E_WARNING will be > promoted to TypeErrors. > > I really do not like these particular horrible behaviors of the language > (huge "yikes" for PHP being so broken): > > * `"123" == "123 "` - do not want - already bad enough that leading > whitespace is ignored here, and already caused some security issues on my > end some years ago > * `is_numeric("123 ") === true` - `is_numeric()` should probably be > soft-deprecated and replaced with something stricter, instead of expanding > this too... > > I don't really care about `declare(strict_types=0), since I don't use it > anymore, nor plan to use it anymore in any foreseeable future, but the two > points above really feel wrong, and I'm conflicted about what to vote. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > Hey Marco, I do agree that accepting trailing whitespace may be considered suboptimal but as leading whitespaces don't even emit an E_NOTICE it is impossible to drop this "feature". Therefore I went for the next best thing which makes it IMHO sane, i.e. accepting trailing whitespaces everywhere. One way to improve the comparison case could be by adding an "eq" op like PERL has which always do a string comparison, basically equivalent to (string) $a === (string) $b as in PERL == always does a numerical comparison, which is not the case in PHP as it tries to be "smart". To address the second point, deprecating is_numeric seems out of scope for this RFC and could be a future scope. Hope this clarifies some of the reasoning. Best regards George P. Banyard --00000000000091b55705aa8fb691--