Re: Digit separators for numeric literals
| From: | Christoph Becker | Date: | Thu, 19 Feb 2015 13:25:12 +0000 |
| Subject: | Re: Digit separators for numeric literals | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83181@lists.php.net to get a copy of this message | ||
Rasmus Lerdorf wrote:
> On 02/18/2015 11:21 PM, Rick Widmer wrote:
>
>> 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 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] <http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10>
--
Christoph M. Becker