# [RFC][VOTE] Number Format Separator

- Thread: https://externals.io/message/90626
- Original archive: https://news-web.php.net/php.internals/90626
- Started by Thomas Punt on 2016-01-13T18:48:45+00:00
- Messages: 11
- RFC: Numeric Literal Separator (Implemented (PHP 7.4)) — https://externals.io/rfc/numeric_literal_separator.md
- RFC: Number Format Separator (Declined) — https://externals.io/rfc/number_format_separator.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #90626 — Thomas Punt — 2016-01-13T18:48:45+00:00

URL: https://externals.io/message/90626#90626

Hi internals!

Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends in
one week's time on January 20th.

Thanks,
Tom

[1]: http://wiki.php.net/rfc/number_format_separator

---

## #90647 — Thomas Punt — 2016-01-14T17:21:43+00:00

URL: https://externals.io/message/90626#90647

Hi Björn,

> Well, if I had a vote it would definetly be +1. A small question
> though, why is the voting period only one week (small RFC or)?

The RFC is quite simple and short, so I thought a one week voting period would
suffice. I'm more than happy to extend this though if people don't think they'll
have time to review it within the next week.

> Regards //Björn Larsson

-Tom

---

## #90673 — Andrea Faulds — 2016-01-16T01:40:46+00:00

URL: https://externals.io/message/90626#90673 · In reply to: #90626

Hi Thomas,

Thomas Punt wrote:
> Hi internals!
>
> Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends in
> one week's time on January 20th.
>
> Thanks,
> Tom
>
> [1]: http://wiki.php.net/rfc/number_format_separator 		 	   		
>

Initially I was going to abstain from this vote, but I've changed my 
mind and I am now voting in favour of the RFC.

When choosing whether to add features to the language, we must set a 
high standard, because every new additions means additional complexity 
and more knowledge PHP developers have to have. So, every new addition 
should be made to fit well with existing features, be useful, and

This feature offers some benefit in some cases. It doesn't introduce 
much new complexity. There's no new syntax or tokens, it just modifies 
the form of the existing number tokens. It fits in well what's already 
there, consistently applying to all number literals. It follows 
established convention in other languages. Its appearance at least hints 
that values with these seperators are not constants or identifiers, but 
numbers, reducing potential for confusion. It limits its own application 
to prevent abuse (no leading, trailing, or repeated separators). And 
it's relatively intuitive.

So I think it might be worth adding, thus my vote. Though we must be 
conservative with additions, this one doesn't seem to be too problematic.

That said, I might be voting the wrong way. The feature does seem to 
have limited applicability. That's really the only thing I can say 
against it.

Thanks.

-- 
Andrea Faulds
https://ajf.me/

---

## #90683 — Stanislav Malyshev — 2016-01-17T22:31:52+00:00

URL: https://externals.io/message/90626#90683

Hi!

> Came to think on license keys for games. They always have a separator
> (using -) to increase readability. Which leads me to thinking, could the
> proposed number separator be used in cryptographic keys and is there
> a value in that?

Probably not. Crypto keys are usually pretty long integers, which would
not fit into standard PHP number. If you want to do your own crypto in
PHP (which is usually not recommended unless you *really really* know
what you are doing) then you'd use something like GMP. But most likely,
you would use standard crypto libraries and standard key storage formats
like PKCS #1.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #90691 — Yasuo Ohgaki — 2016-01-18T08:12:12+00:00

URL: https://externals.io/message/90626#90691 · In reply to: #90673

Hi all,


>
> Thomas Punt wrote:
> > […]
>
> Initially I was going to abstain from this vote, but I've changed my mind
> and I am now voting in favour of the RFC.
>
> When choosing whether to add features to the language, we must set a high
> standard, because every new additions means additional complexity and more
> knowledge PHP developers have to have. So, every new addition should be made
> to fit well with existing features, be useful, and
>
> This feature offers some benefit in some cases. It doesn't introduce much
> new complexity. There's no new syntax or tokens, it just modifies the form
> of the existing number tokens. It fits in well what's already there,
> consistently applying to all number literals. It follows established
> convention in other languages. Its appearance at least hints that values
> with these seperators are not constants or identifiers, but numbers,
> reducing potential for confusion. It limits its own application to prevent
> abuse (no leading, trailing, or repeated separators). And it's relatively
> intuitive.
>
> So I think it might be worth adding, thus my vote. Though we must be
> conservative with additions, this one doesn't seem to be too problematic.
>
> That said, I might be voting the wrong way. The feature does seem to have
> limited applicability. That's really the only thing I can say against it.

The same opinion.
The syntax is popular enough and doesn't add much complexity, but
it seems this RFC wouldn't pass.

Large numeric literals are not used often. However if it is used, it's
frustrating to read. e.g. Code audit/review. Why not make computer
do the job?

I hope more people change their mind.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #90693 — Lester Caine — 2016-01-18T12:22:43+00:00

URL: https://externals.io/message/90626#90693 · In reply to: #90691

> Large numeric literals are not used often. However if it is used, it's
> frustrating to read. e.g. Code audit/review. Why not make computer
> do the job?
> 
> I hope more people change their mind.

Where large numbers are used, adding them as strings using the local
format is already used? This just adds yet another 'option' to how they
can be entered but is something which makes reading in the context of
the local use MORE of a problem? My main need would be hexadecimal code
which is not covered, so I still need the alternate hacks anyway.

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

---

## #90694 — Leigh — 2016-01-18T12:25:41+00:00

URL: https://externals.io/message/90626#90694 · In reply to: #90693

>
> My main need would be hexadecimal code
> which is not covered, so I still need the alternate hacks anyway.
>

Hex is covered, see the first examples in the "Proposal" section

---

## #90696 — Lester Caine — 2016-01-18T12:43:54+00:00

URL: https://externals.io/message/90626#90696 · In reply to: #90694

>     My main need would be hexadecimal code
>     which is not covered, so I still need the alternate hacks anyway.
> 
> Hex is covered, see the first examples in the "Proposal" section 

Sorry getting mixed up ;)
Can't use the 0x in some areas, so one ends up with an alternate method
of adding the data as hex ... with it's own separator ... but for the
life of me I can't find why we had to do that now. This may be down to
BIGINT and 64bit numbers in databases ... that is where the data ends up
and I know the 0x was a problem - or was it octal input

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

---

## #90702 — bjorn.x.larsson@telia.com — 2016-01-18T16:49:25+00:00

URL: https://externals.io/message/90626#90702 · In reply to: #90693

Den 2016-01-18 kl. 13:22, skrev Lester Caine:
> 
> > […]
> Where large numbers are used, adding them as strings using the local
> format is already used? This just adds yet another 'option' to how they
> can be entered but is something which makes reading in the context of
> the local use MORE of a problem? My main need would be hexadecimal code
> which is not covered, so I still need the alternate hacks anyway.
>
Hm... I got the impression it was covered by reading the two last
examples of: "Enable for arbitrary grouping of digits". Did I read
it to quick?

r//Björn

---

## #90739 — Thomas Punt — 2016-01-20T20:42:32+00:00

URL: https://externals.io/message/90626#90739 · In reply to: #90626

Hi internals!

> Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends in
> one week's time on January 20th.

Voting has now ended with 20 for and 18 against. This means the RFC has been
declined.

Thank you to all who participated in the RFC discussion and voting!

-Tom

---

## #90746 — Yasuo Ohgaki — 2016-01-20T22:05:10+00:00

URL: https://externals.io/message/90626#90746

Hi Andrea,


>
> One other approach I thought of is to use constant scalar expressions:
>
> +('123'.'456'.'789')
>
> It's not quite the same of native support, but it works.

This is what I do on occasions.

I have to read `var_export()`ed PHP code sometimes.
If PHP supports this RFC and `var_export()` support it,
it would be much easier to read.

It's irrelevant for this RFC, but if PHP supports compile
time string concatenation

echo "Very long sting "
        "that is concatenated "
        "at compile time.";

It would be nice to have.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net