Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105074 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11427 invoked from network); 4 Apr 2019 18:10:09 -0000 Received: from unknown (HELO mail-lj1-f169.google.com) (209.85.208.169) by pb1.pair.com with SMTP; 4 Apr 2019 18:10:09 -0000 Received: by mail-lj1-f169.google.com with SMTP id v13so2408385ljk.4 for ; Thu, 04 Apr 2019 08:05:49 -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=3Cu88xta5s4pzCihp607rXFOSRB+N2+iMK+bkL+hq64=; b=T8EApbt0ZNsO1EYSSaUrDbLJsD+M5X6GkNS7fXRMwyuAlkuRnBg4JfEhrNHfMQeIGd tO7Ccac3N4xFQgEtINi4Yp2Bwqm7R6OHmCq2levh8bXKdfro62fAPV3b8gamNToPG7gB PR9uroJc1erXTMXh6tNRe5ZRmIiJeNECUWbYZxAz6SColpPqFZYYhEomQFlFRchUbQmT E8U9OQtRmDaViTvNLa/SmmVw4De6Cp25a5JaU++10pHslvd65H8GziqaJH/1i8r66xur 3ZFLHmN2iqv9g+cm4fzZJaQfiCpUOPKMwEIjvJjEZ707HimO78rp8h9ueAAtTTSp0eVs KO8Q== 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=3Cu88xta5s4pzCihp607rXFOSRB+N2+iMK+bkL+hq64=; b=GQgejWCRbkK42mJAllvMQ+ix7dIJv3tKV28yqWp99aJwKBCeagbD6fFMkqR0bF9ys8 sqeOgTQV+INaP4T0rdv7ZIEV3oq1e+DbkV/98/fHVHEDavP3CIugVEiGVzpeN69dBLEh AcmLWlo4AT65fy/X2NKlsBbNO5n5026rYgqsr4OgTYDIocSp3pEOieFnAE7afagU6h83 WL/9SGvrqp8fII1CCy29d2USZufGE/cR6nMLIvp7N30zZgrm/VhlvsQQfTpXQehWzvM1 /dB40Zd33PWUks1hxo+A9CEXUR1qIJ79zKfFw/T5QoerMzAR+8H99lCypou5yByH5AnB NPqw== X-Gm-Message-State: APjAAAWVipC5DPFxLu55HR99PWtzEG2zfG+NE4WPCvJPuZnt6/Xv2Fru j8xh+KSpfszouvCk9Ir1TBkzebNO+B4+VWi572A= X-Google-Smtp-Source: APXvYqwMt1xnh9sf4jgwOuGU58dPnCOhMekoGPO1mOxbq/6os9mXgQ1vIo1NwAue//dhszgMyZvh6IWAlvNNkNdftJw= X-Received: by 2002:a2e:8648:: with SMTP id i8mr3791070ljj.166.1554390348850; Thu, 04 Apr 2019 08:05:48 -0700 (PDT) MIME-Version: 1.0 References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name> <5ca53ea8.1c69fb81.d773b.1df3SMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: Date: Thu, 4 Apr 2019 08:05:38 -0700 Message-ID: To: Benjamin Morel Cc: Andrea Faulds , PHP Internals Content-Type: multipart/alternative; boundary="00000000000095eae30585b5b498" Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings From: mo.mu.wss@gmail.com ("M. W. Moe") --00000000000095eae30585b5b498 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, what about exposing a strict keyword option or a php ini option? - NO - leave as it is default - YES - allow trailing whitespace punks - YES - disallow leading whitespace sane people On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel wrote: > What about going forward with the trailing whitespace RFC right now, but > ask to vote between 3 options? > > - NO - leave as it is > - YES - allow trailing whitespace > - YES - disallow leading whitespace > > And then proceeding with the string to number comparison RFC? > > Ben > > On Thu, 4 Apr 2019 at 01:15, Andrea Faulds wrote: > > > Nikita Popov wrote: > > > I'm always a fan of making things stricter, but think that in this > > > particular case there are some additional considerations we should ke= ep > > 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 maki= ng > > 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 resol= ve > > 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 whitespac= e. > > > > I'm kinda unsure how to go forward because of these points. I would lik= e > > to see improved comparisons, and I would like to see the end of the > > =E2=80=9Cnon-well-formed=E2=80=9D numeric string, and I think this whit= espace RFC could > > be helpful to both. But I can't see the future, I don't know whether > > people will vote for removing leading or permitting traiing whitespace > > and whether or not they will be influenced by or this will influence > > opinion on the further improvements. =C2=AF\_(=E3=83=84)_/=C2=AF > > > > I'm torn between: > > > > * Vote on allowing trailing whitespace > > * Vote on disallowing leading whitespace > > * Vote on which of those two approaches to go for > > * Trying to bundle everything together and voting on it as a package. > > > > I'm probably thinking too strategically. > > > > Andrea > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > --00000000000095eae30585b5b498--