Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105456
MIME-Version: 1.0
References: <DM5PR06MB28578FFCD3349CF7F41F33FDDE3D0@DM5PR06MB2857.namprd06.prod.outlook.com>
 <CAEYWF=7dVBsbFUnK27OV7rfg7e=rsZ9jcv0Q=VFKND6p=OPYFA@mail.gmail.com> <CAEYWF=7s5CW-zAobmJYvr5hj9-K7gU123WVkjZwnth-p-9uYLQ@mail.gmail.com>
In-Reply-To: <CAEYWF=7s5CW-zAobmJYvr5hj9-K7gU123WVkjZwnth-p-9uYLQ@mail.gmail.com>
Date: Fri, 26 Apr 2019 12:10:00 +0100
Message-ID: <CALKiJKp5q_ja54S7o-H56iWjegfXCmhvDSy-cO6wBxj4roc-mA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000076bfa605876cfac2"
Subject: Re: [PHP-DEV] Revive Number Format Separator RFC
From: rowan.collins@gmail.com (Rowan Collins)

--00000000000076bfa605876cfac2
Content-Type: text/plain; charset="UTF-8"

> > On Thu, Apr 25, 2019 at 6:07 PM Theodore Brown <theodorejb@outlook.com>
> > wrote:
> >
> >> Is there any chance the Number Format Separator RFC [1] could be revived
> >> for PHP 7.4? I looked at the discussion from a few years ago and it's
> not
> >> clear why many people originally voted against it.
>


Hi,

I'm not particularly against this proposal, but I'm not sure how often I'd
use it.


On Fri, 26 Apr 2019 at 06:15, Bishop Bettini <bishop@php.net> wrote:

A cursory scan of current usage suggests that number format separator might
> be used in scenarios such as:
>
> Phone numbers
> 919_555_1234
> 49_89_636_48018
>


This is a poor example, because phone numbers shouldn't be stored as
integers; there's nothing you can do with them mathematically, and outside
of North America it's extremely common for them to have significant leading
zeroes.



> Date time values
> 2018_04_26
> 20180426_183242
>


Again, I can't see why you'd ever use an integer for that, rather than a
string. Were there really integer literals of this form in the packages you
searched?



> For those first few, Kotlin has similar examples [2], but Javascript
> discourages use of number separator in "number-ish" values (eg phone
> numbers) [3].
>


The second article you link to isn't official documentation, just someone's
blog post about the feature. I agree with the comment, though - the Kotlin
example of a credit card number wouldn't pass code review with me, because
they're not really "numbers", they're identifiers which happen to only use
digits (the only mathematical operation on a card number would be checking
the Luhn checksum, which is a digit-by-digit operation anyway).


The only example that I can see myself using is the one of money-as-cents
(or, in my case, pence):

$pricePence = 1000_00; // GBP 1000.00

Although some kind of struct with separate fields and overloaded operators
would probably be better still:

$price = Money{ 'GBP', 1000, 00 };


The main use I've had for large number literals is for things like cache
lifetimes, where the extra syntax wouldn't help, but constant expressions
do:

$lifetimeSecs = 604800; // 7 days

const SECONDS_IN_MINUTE = 60;
const SECONDS_IN_HOUR = SECONDS_IN_MINUTE * 60;
const SECONDS_IN_DAY = SECONDS_IN_HOUR * 24;
$lifetimeSecs = 7 * SECONDS_IN_DAY;


Similar approaches work for other contexts, for instance:

const GIBIBYTE = 1024 ** 3;
const GIBIBYTE = 2 ** 30;

both read more clearly than anything you could do with underscores:

const GIBIBYTE = 1_073_741_824;
const GIBIBYTE = 0x40_000_000;
const GIBIBYTE = 0b1_00000_00000_00000_00000_00000_00000;

Regards,
-- 
Rowan Collins
[IMSoP]

--00000000000076bfa605876cfac2--