# Digit separators for numeric literals - Thread: https://externals.io/message/83140 - Original archive: https://news-web.php.net/php.internals/83140 - Started by Christoph Becker on 2015-02-19T02:07:42+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #83140 — Christoph Becker — 2015-02-19T02:07:42+00:00 URL: https://externals.io/message/83140#83140 Hi internals! A while ago a question was asked on the php-general mailing list with regard to digit seperators in numeric literals[1]. IMHO it might be a useful enhancement to allow such digit separators for numeric (integer and float) literals in PHP for better readability; several other languages already support them (such as Java, Perl, Ruby, C#, Eiffel and C++14). Before attempting to draft a respective RFC, I'd like to get some feedback, whether this is generally considered to be useful, which character would be preferred (most other languages seem to allow the underscore, but an apostroph or maybe some other character might be reasonable as well), and which restrictions should be applied (e.g. arbitrary use of the separator, group thousands only, etc.) I'm looking forward to hear your opinion. Thanks in advance. [1] -- Christoph M. Becker --- ## #83141 — Rasmus Lerdorf — 2015-02-19T02:44:46+00:00 URL: https://externals.io/message/83140#83141 · In reply to: #83140 > Hi internals! > > A while ago a question was asked on the php-general mailing list with > regard to digit seperators in numeric literals[1]. > > IMHO it might be a useful enhancement to allow such digit separators for > numeric (integer and float) literals in PHP for better readability; > several other languages already support them (such as Java, Perl, Ruby, > C#, Eiffel and C++14). > > Before attempting to draft a respective RFC, I'd like to get some > feedback, whether this is generally considered to be useful, which > character would be preferred (most other languages seem to allow the > underscore, but an apostroph or maybe some other character might be > reasonable as well), and which restrictions should be applied (e.g. > arbitrary use of the separator, group thousands only, etc.) > > I'm looking forward to hear your opinion. Thanks in advance. > > [1] I think it will be difficult to find a separator character that doesn't make a mess of the grammar. my_func(1,999,999) obviously doesn't work my_func(1'999'999) as per C++14 clashes with our single-quoted strings my_func(1_999_999) like in ADA might work but _999_ would need to work as well and _ is a valid char in a constant so you can have a constant named _999_. - nope # nope @ nope ~ nope ! nope % nope ^ nope We went through this for the namespace char, and there simply isn't a typable single character left to use for something like this. _ is the closest but it would require some changes and BC breaks which I am not sure is worth for what appears to me to be a not-so critical feature. Now if we went into Unicode territory, we could do it. eg. my_func(1 999 999) U+1680 (although it looks too much like a -) my_func(1 999 999) U+205F (mathematical space) my_func(1٬999٬999) U+066C (Arabic thousands separator) my_func(1·999·999) U+00B7 (middle dot) The last one looks best to me, but we'd need a team of people working in shifts to answer the, "How do I type this?" question. -Rasmus --- ## #83150 — Rick Widmer — 2015-02-19T07:21:42+00:00 URL: https://externals.io/message/83140#83150 · In reply to: #83141 > > > […] > > I think it will be difficult to find a separator character that doesn't > make a mess of the grammar. > > my_func(1,999,999) obviously doesn't work > my_func(1'999'999) as per C++14 clashes with our single-quoted strings > my_func(1_999_999) like in ADA might work > > but _999_ would need to work as well and _ is a valid char in a constant > so you can have a constant named _999_. > > - nope > # nope > @ nope > ~ nope > ! nope > % nope > ^ nope > > We went through this for the namespace char, and there simply isn't a > typable single character left to use for something like this. _ is the > closest but it would require some changes and BC breaks which I am not > sure is worth for what appears to me to be a not-so critical feature. > > Now if we went into Unicode territory, we could do it. eg. > > my_func(1 999 999) U+1680 (although it looks too much like a -) > my_func(1 999 999) U+205F (mathematical space) > my_func(1٬999٬999) U+066C (Arabic thousands separator) > my_func(1·999·999) U+00B7 (middle dot) > > The last one looks best to me, but we'd need a team of people working in > shifts to answer the, "How do I type this?" question. > > -Rasmus how about: my_func( '1,000.04' ); //if you want to use separators there. Rick. Who is firmly in the camp that considers type juggling an essential feature of PHP. --- ## #83153 — Rasmus Lerdorf — 2015-02-19T07:46:18+00:00 URL: https://externals.io/message/83140#83153 · In reply to: #83150 > > > […] > > how about: > > my_func( '1,000.04' ); //if you want to use separators there. The problem with that is that the world is split. The other half, or actually more than half, would write that as '1.000,04'. There is no way we would want to take sides on that one. And we have support for locale-based number formatting and parsing via numfmt_format() and numfmt_parse(). If we were going to add a separator for literals, the only real low-ascii choice is _ which is also used by Ada, D, Java, Perl and Ruby. I was 90% kidding about using a Unicode character, but if you think about it a bit, most people are using IDEs or at least smart scriptable editors, it wouldn't be that much of a stretch to picture your editor pretty-printing 1234567890 as 1·234·567·890 or 1˙234˙567˙890 (U+02D9). It would be easy to make the parser ignore that character in numeric literals. Much easier than working out the various issues with _ anyway. Although, personally it would freak me out if my editor started messing with my numbers on me. But I don't use an IDE. I don't even have syntax-highlighting turned on in my vim config. We didn't have stuff like that on the Wyse 50. -Rasmus --- ## #83154 — Michael Wallner — 2015-02-19T07:49:29+00:00 URL: https://externals.io/message/83140#83154 · In reply to: #83141 > but _999_ would need to work as well and _ is a valid char in a constant > so you can have a constant named _999_. > Why would we need to support the underscore in front (and maybe even at the end) of a number? -- Regards, Mike --- ## #83156 — Rasmus Lerdorf — 2015-02-19T08:11:52+00:00 URL: https://externals.io/message/83140#83156 · In reply to: #83154 > > > > […] > > Why would we need to support the underscore in front (and maybe even at > the end) of a number? I guess we could restrict it to not be leading. I was thinking along the lines of the character being defined to be ignored anywhere in a literal. The underscore was actually rejected in C++14 because C++ has user defined literals. http://en.cppreference.com/w/cpp/language/user_literal which would then make 0x12_ab problematic. We obviously don't have user-defined literals so we probably could make it work. Like I said, that is the only viable option as far as I can see. -Rasmus --- ## #83173 — Nikita Nefedov — 2015-02-19T12:16:22+00:00 URL: https://externals.io/message/83140#83173 · In reply to: #83141 2015-02-19 6:44 GMT+04:00 Rasmus Lerdorf : > > I think it will be difficult to find a separator character that doesn't > make a mess of the grammar. > > my_func(1,999,999) obviously doesn't work > my_func(1'999'999) as per C++14 clashes with our single-quoted strings > my_func(1_999_999) like in ADA might work > > but _999_ would need to work as well and _ is a valid char in a constant > so you can have a constant named _999_. > > - nope > # nope > @ nope > ~ nope > ! nope > % nope > ^ nope > > We went through this for the namespace char, and there simply isn't a > typable single character left to use for something like this. _ is the > closest but it would require some changes and BC breaks which I am not > sure is worth for what appears to me to be a not-so critical feature. > > Now if we went into Unicode territory, we could do it. eg. > > my_func(1 999 999) U+1680 (although it looks too much like a -) > my_func(1 999 999) U+205F (mathematical space) > my_func(1٬999٬999) U+066C (Arabic thousands separator) > my_func(1·999·999) U+00B7 (middle dot) > > The last one looks best to me, but we'd need a team of people working in > shifts to answer the, "How do I type this?" question. > > -Rasmus > > Hey, Why not space? It's certainly possible (I just checked) and it would look clear I guess: my_func(1 999 999); --- ## #83181 — Christoph Becker — 2015-02-19T13:25:12+00:00 URL: https://externals.io/message/83140#83181 · In reply to: #83153 Rasmus Lerdorf wrote: > > > > […] > > The problem with that is that the world is split. The other half, or > actually more than half, would write that as '1.000,04'. There is no way > we would want to take sides on that one. And we have support for > locale-based number formatting and parsing via numfmt_format() and > numfmt_parse(). If we were going to add a separator for literals, the > only real low-ascii choice is _ which is also used by Ada, D, Java, Perl > and Ruby. I agree that _ is most reasonable, mainly because it is used by other languages also. > I was 90% kidding about using a Unicode character, but if you think > about it a bit, most people are using IDEs or at least smart scriptable > editors, it wouldn't be that much of a stretch to picture your editor > pretty-printing 1234567890 as 1·234·567·890 or 1˙234˙567˙890 (U+02D9). > It would be easy to make the parser ignore that character in numeric > literals. Much easier than working out the various issues with _ anyway. Which issues do you see? IMHO it doesn't make much sense to use a digit separator in a trailing or leading position, because that wouldn't improve readability. So PHP could make the same restrictions as Java with regard to integer and float literals[1] (basically that the underscore is allowed only between actual digits), in which case I don't see any syntactic ambiguity. Ignoring the _ in the scanner (IMHO there is no need to obtain it in the token) doesn't seem to be harder than ignoring any other character. [1] -- Christoph M. Becker --- ## #83182 — Michael Wallner — 2015-02-19T13:26:45+00:00 URL: https://externals.io/message/83140#83182 · In reply to: #83173 > > Why not space? It's certainly possible (I just checked) and it would look > clear I guess: > > my_func(1 999 999); > Yes, but what if I just missed one or two commas there? ;) -- Regards, Mike --- ## #83233 — Christoph Becker — 2015-02-19T19:07:24+00:00 URL: https://externals.io/message/83140#83233 · In reply to: #83173 Nikita Nefedov wrote: > 2015-02-19 6:44 GMT+04:00 Rasmus Lerdorf : > > […] > > Why not space? It's certainly possible (I just checked) and it would look > clear I guess: > > my_func(1 999 999); By the same reasoning spaces could be allowed for identifiers as well, e.g. my func(1 999 999); Too confusing and error prone, IMHO. -- Christoph M. Becker