Revive Number Format Separator RFC

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.

JavaScript and Python have both gotten this feature recently and it's something I really miss in PHP when declaring/reading large numbers.

Maybe it would help to simplify how the restrictions are described in the RFC. As I understand it, the only restriction is that each underscore in a numeric literal must be between two digits. Perhaps the way the RFC described this syntax made it seem more complex than it is.

Best regards,

Theodore Brown

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.

JavaScript and Python have both gotten this feature recently and it's
something I really miss in PHP when declaring/reading large numbers.

Maybe it would help to simplify how the restrictions are described in the
RFC. As I understand it, the only restriction is that each underscore in a
numeric literal must be between two digits. Perhaps the way the RFC
described this syntax made it seem more complex than it is.

Best regards,

Theodore Brown

Subsequent conversation occurred on the voting thread 1, which wasn't
included by reference in the RFP itself.

The only dissent I saw in that thread came from Pascal Martin, speaking for
AFUP, who wrote 2:

it would be harder to search in code, as there would be more than
one way to write a number. Basically, it would break grep/find.
Splitting numbers so they are more readable is kind of a presentation
matter and, as such, could be done by an editor/IDE when displaying
code, without having to modify the code by hand

Related: the RFC author Tom Punt also detailed the implementation, but
didn't incorporate that by reference into the RFC 3. Worth the read.

With Tom's blessing, I'd support re-visiting this feature. It's useful, IMO.

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.

JavaScript and Python have both gotten this feature recently and it's
something I really miss in PHP when declaring/reading large numbers.

Maybe it would help to simplify how the restrictions are described in the
RFC. As I understand it, the only restriction is that each underscore in a
numeric literal must be between two digits. Perhaps the way the RFC
described this syntax made it seem more complex than it is.

Best regards,

Theodore Brown

Subsequent conversation occurred on the voting thread 1, which wasn't
included by reference in the RFP itself.

The only dissent I saw in that thread came from Pascal Martin, speaking
for AFUP, who wrote 2:

it would be harder to search in code, as there would be more than
one way to write a number. Basically, it would break grep/find.
Splitting numbers so they are more readable is kind of a presentation
matter and, as such, could be done by an editor/IDE when displaying
code, without having to modify the code by hand

Related: the RFC author Tom Punt also detailed the implementation, but
didn't incorporate that by reference into the RFC 3. Worth the read.

With Tom's blessing, I'd support re-visiting this feature. It's useful,
IMO.

Using a variant of Nikita's top packages visitor 1, the top 250 packages
contain about 3 million integer literals. Of those, about 800k have 5 or
more digits, while only about 3k have 10 or more digits. Nine digits is
unusually common, because of its use in giggsey/libphonenumber-for-php for
United States phone numbers.

Applying some rough heuristics to file names, 89% of those literals appear
in a data file, 8% in code, and 3% in tests.

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

Date time values
2018_04_26
20180426_183242

Range end points (using any locale's grouping strategy)
2_147_483_647
1_67_77_215

Nibble groups
0b0011_1111_0100_1110

For those first few, Kotlin has similar examples 2, but Javascript
discourages use of number separator in "number-ish" values (eg phone
numbers) 3.

https://gist.github.com/bishopb/157d403dc1c190957a558c93e120a07d

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.

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]

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.

Along with flagging the country code with a '+' ...

--
Lester Caine - G8HFL

Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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.

I'm not particularly against this proposal, but I'm not sure how often I'd
use it.

How often you use numeric separators depends on what you are doing.
I definitely agree that phone numbers and dates are not good use cases,
and that there are usually better ways to write things like the number
of seconds in a day or number of bytes in a gigabyte.

However, there are many other appropriate uses of large integers
where numeric separators can make the code more readable and
prevent mistakes. Here's an example from code I maintain:

function getActiveDirectoryTimestamp(DateTime $date): int
{
    // Active Directory stores dates as the number of 100-nanosecond
    // intervals since January 1, 1601.
    $epochDiff = 11_644_473_600;
    $secondsAfterADEpoch = $date->getTimestamp() + $epochDiff;
    return $secondsAfterADEpoch * 10_000_000;
}

Another common use case is constants used in scientific calculations:

const ASTRONOMICAL_UNIT = 149_597_870_700;
const SPEED_OF_LIGHT = 299_792_458;

echo 'Time for light to travel from sun to earth: ';
echo (ASTRONOMICAL_UNIT / SPEED_OF_LIGHT) . ' sec.';

For me personally the most frequent use case is actually in tests,
where various values (e.g. large dollar amounts) are passed to
functions in order to validate business logic. Numeric separators
would help make such unit tests a lot more readable.

Best regards,

Theodore Brown

Hi!

I'm not particularly against this proposal, but I'm not sure how often I'd
use it.

How often you use numeric separators depends on what you are doing.
I definitely agree that phone numbers and dates are not good use cases,
and that there are usually better ways to write things like the number
of seconds in a day or number of bytes in a gigabyte.

Storing dates in an integer format can be a valid use case if performance is a
concern. It is far faster and more compact to store and compare integer-based
dates than using objects for everything.

Anyway, if anyone would like to revive this RFC, then feel free to!

Thanks,
Tom

Storing dates in an integer format can be a valid use case if
performance is a
concern. It is far faster and more compact to store and compare
integer-based
dates than using objects for everything.

The only way I've seen dates stored as integers is as a number of
seconds / milliseconds / whatever since some epoch, most commonly
seconds since 1970-01-01 00:00:00 UTC

The format Bishop seemed to be suggesting would be absolutely useless
for anything other than the simplest comparisons: how do you add a day
to the date-as-number 20190430?

I'm sure there are use cases for this syntax, but the examples in that
e-mail were poorly chosen.

Regards,

--
Rowan Collins
[IMSoP]

The only way I've seen dates stored as integers is as a number of
seconds / milliseconds / whatever since some epoch, most commonly
seconds since 1970-01-01 00:00:00 UTC

Use of a days count rather than a seconds count makes dates a lot easier
to work with. 2 32bit numbers give a substantial day count along with
either fractional time of day or alternatively a second count for the
day. Genealogical data is substantially easier to manage as a day count
which can be expanded in accuracy with a time count either viewed as
integers or as floating point numbers ... leap seconds just get hidden
in the processing.

--
Lester Caine - G8HFL

Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

The only way I've seen dates stored as integers is as a number of
seconds / milliseconds / whatever since some epoch, most commonly
seconds since 1970-01-01 00:00:00 UTC

Use of a days count rather than a seconds count makes dates a lot
easier
to work with. 2 32bit numbers give a substantial day count along with
either fractional time of day or alternatively a second count for the
day.

That makes sense, but it's still a variant on the epoch + count concept, not year-month-day as in Bishop's example. As such, it still wouldn't particularly benefit from separators; you'd probably write constants in string form and convert them on the fly, or have durations which were multiples of 7 or 365 rather than powers of 10 or 16.

Regards,

--
Rowan Collins
[IMSoP]

Hi!

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

Just noting here that using integers as phone numbers is not something
we want to support, enable or promote.

Date time values
2018_04_26
20180426_183242

Same here, these are not integers (or numbers).

Range end points (using any locale's grouping strategy)
2_147_483_647
1_67_77_215

These are numbers, but should be only ever used in constants (with
appropriate comment).

I am not exactly against this feature, but the potential for abuse -
like enabling people using integers for things that are not integers and
should not be stored as integers - worries me now.

Stas Malyshev
smalyshev@gmail.com

I am not exactly against this feature, but the potential for abuse
- like enabling people using integers for things that are not
integers and should not be stored as integers - worries me now.

Based on the usage analysis Bishop did, people already use integers
for number-like values (e.g. phone and social security numbers) that
can be better represented in other ways.

Perhaps adding the numeric separator feature can actually be an
opportunity to discourage such misuse. We can add a paragraph to the
RFC (and the documentation if it is accepted) that lists examples of
usage that should be avoided.

Ultimately there remains many legitimate uses of large numbers in
code (e.g. scientific constants, unit test values, business logic
thresholds, etc.), and this feature is a simple way to improve their
readability.

I've lost count of the number of times I've been debugging a failing
test and struggling to count the number and position of digits to
make sure I have the right value. This feature would save time when
reading code and indeed prevent a lot of mistakes in the first place.

On Sun, Apr 28, 2019 at 1:47 PM Theodore Brown theodorejb@outlook.com
wrote:

On Sat, Apr 27, 2019 at 10:25 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

I am not exactly against this feature, but the potential for abuse
- like enabling people using integers for things that are not
integers and should not be stored as integers - worries me now.

Based on the usage analysis Bishop did, people already use integers
for number-like values (e.g. phone and social security numbers) that
can be better represented in other ways.

Perhaps adding the numeric separator feature can actually be an
opportunity to discourage such misuse. We can add a paragraph to the
RFC (and the documentation if it is accepted) that lists examples of
usage that should be avoided.

Ultimately there remains many legitimate uses of large numbers in
code (e.g. scientific constants, unit test values, business logic
thresholds, etc.), and this feature is a simple way to improve their
readability.

I've lost count of the number of times I've been debugging a failing
test and struggling to count the number and position of digits to
make sure I have the right value. This feature would save time when
reading code and indeed prevent a lot of mistakes in the first place.

Well said.

One need not agree with an implementation to appreciate the improved
readability.

If you'd like to re-open this for voting, I'm able to assist with the RFC
process and any code changes.

Well said.

One need not agree with an implementation to appreciate the improved
readability.

If you'd like to re-open this for voting, I'm able to assist with
the RFC process and any code changes.

Thanks! I drafted a preliminary RFC, but I'll need assistance with
the implementation and publishing the RFC on wiki.php.net.

https://gist.github.com/theodorejb/653221e3221b2b4d2ad8fa94d3a963ff

On Tue, Apr 30, 2019 at 4:41 PM Theodore Brown theodorejb@outlook.com
wrote:

Well said.

One need not agree with an implementation to appreciate the improved
readability.

If you'd like to re-open this for voting, I'm able to assist with
the RFC process and any code changes.

Thanks! I drafted a preliminary RFC, but I'll need assistance with
the implementation and publishing the RFC on wiki.php.net.

https://gist.github.com/theodorejb/653221e3221b2b4d2ad8fa94d3a963ff

Excellent. I hope we can make the case this time. Please request Wiki karma
1, and we'll iterate on it there.

Excellent. I hope we can make the case this time. Please
request Wiki karma [1], and we'll iterate on it there.

I was granted karma, and published an initial RFC draft:
https://wiki.php.net/rfc/numeric_literal_separator.

I would greatly appreciate help with the implementation, since I
don't have much experience with C and haven't contributed to PHP before.

Also let me know if you have any ideas for improving the RFC.

I am happy to help with these. Let us take the RFC refinement and
implementation details conversation off-list. Then come back when prepared
to present for discussion.

Hi!

Excellent. I hope we can make the case this time. Please
request Wiki karma 1, and we'll iterate on it there.

I was granted karma, and published an initial RFC draft:
https://wiki.php.net/rfc/numeric_literal_separator.

I would greatly appreciate help with the implementation, since I
don't have much experience with C and haven't contributed to PHP before.

Also let me know if you have any ideas for improving the RFC.

I am happy to help with these. Let us take the RFC refinement and
implementation details conversation off-list. Then come back when prepared
to present for discussion.

I would think that pretty much the whole of the original implementation1 should
be reusable (maybe some merge conflicts to fix only). But anyway, I can offer some
support with the implementation, if needed.

Thanks,
Tom

Hi!

On Tue, Apr 30, 2019, 19:14 Theodore Brown <theodorejb@outlook.com
wrote:

Excellent. I hope we can make the case this time. Please
request Wiki karma [1], and we'll iterate on it there.

I was granted karma, and published an initial RFC draft:
https://wiki.php.net/rfc/numeric_literal_separator.

I would greatly appreciate help with the implementation, since I
don't have much experience with C and haven't contributed to PHP
before.

Also let me know if you have any ideas for improving the RFC.

I am happy to help with these. Let us take the RFC refinement and
implementation details conversation off-list. Then come back when
prepared
to present for discussion.

I would think that pretty much the whole of the original implementation[1]
should
be reusable (maybe some merge conflicts to fix only). But anyway, I can
offer some
support with the implementation, if needed.

Great, thanks Tom. Theodore and I are polishing the RFC, then will tackle
the implementation. Besides the necessary merge fixes, are there any
changes/improvements you specifically want to make in the new proposed
implementation?

Great, thanks Tom. Theodore and I are polishing the RFC, then will tackle the implementation. Besides the necessary merge fixes, are there any changes/improvements you specifically want to make in the new proposed implementation?

None that I can see/think of. Good luck with the RFC!

-Tom