[RFC] Number Format Separator

You mention no support for numeric strings, but how will settype($string,
int|float), intval(), floatval(), is_numeric() and ctype_digit() work with
this change?

I do think if you don't change the semantics for strings to number
conversion (which I agree you can't due to BC breaks) there should be an
explicit way to support "1_000_000" => (int) 1_000_000. This should be part
of the RFC.

I presume that if you were to go from numeric to string the underscores
would be stripped? What about a way not to do that? What will var_dump()
etc. show?

I think that he is just talking about numeric constants in programs; he is not
talking about run time strings (eg read from a file/form) being allowed to
contain '_'.

Perl does exactly what Thomas is proposing, it does improve readability.

There is not a BC problem since today something like 1_000 is illegal as a
constant in a program.

I think that it is a good idea.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

how will settype($string, int|float), intval(), floatval(), is_numeric()
and ctype_digit() work with this change?

My understanding is that those functions will continue to work as they
do currently. The numeric literals are resolved by the compiler into
numbers when the code is compiled, so there will be no difference.
i.e. this RFC does not affect PHP at runtime at all, only the compile
step.

What will var_dump() etc. show?

var_dump(1_000_000) will have the same output as var_dump(1000000)

there should be an explicit way to support "1_000_000" => (int) 1_000_000. This
should be part of the RFC.

I don't think it should be part of this RFC. That sounds like a
completely different RFC, or is covered by NumberFormatter::parse().

cheers
Dan

Hi Davey,

Davey Shafik wrote:

You mention no support for numeric strings, but how will settype($string,
int|float), intval(), floatval(), is_numeric() and ctype_digit() work with
this change?

I do think if you don't change the semantics for strings to number
conversion (which I agree you can't due to BC breaks) there should be an
explicit way to support "1_000_000" => (int) 1_000_000. This should be part
of the RFC.

I presume that if you were to go from numeric to string the underscores
would be stripped? What about a way not to do that? What will var_dump()
etc. show?

Numeric string conversions, in all their forms (I'm including intval()
and such here) don't follow the same rules as PHP's integer and float
literals. This isn't at all new. Here's some examples of existing
differences between literals and numeric strings:

• "0x123" != 0x123

  Hexadecimal isn't supported in numeric strings.

• "-0.0" != -0.0

  PHP's numeric literals do not have signs. Rather, a preceding - or +
  symbol is parsed as a unary minus/plus. Before PHP 7.0.2, negating
  a floating-point zero did not produce negative zero, which was
  incorrect behaviour.
  PHP's numeric string parser, however, does support signs, and
  interprets "-0.0" is meaning negative zero.

• "0123" != 0123

  Octal isn't supported in numeric strings.

• "0b101" != 0b101

  Binary isn't supported in numeric strings.

• 0 + "-9223372036854775808" !== -9223372036854775808

  As previously mentioned, PHP's numeric literals lack signs. Here, this
  means that -9223372036854775808 is parsed as -(9223372036854775808).
  9223372036854775808 is too large to be an integer, so it is a float.
  However, PHP's numeric string parser does support signs, and
  "-9223372036854775808" fits within the range of an integer.

As you can see, not supporting _ as a number separator here would not be
terribly surprising. It would also be a backwards-compatibility break:
currently, (int)"123_4" is parsed as 123, but it would be 1234 if we
changed the coercion rules.

Thanks.

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

Thomas Punt wrote:

I'd like to propose for the inclusion of a digit separator in PHP. This will
help to promote the readability of numerical literals in code by enabling for
the underscore character to be used in between digits.

RFC: https://wiki.php.net/rfc/number_format_separator
PR: https://github.com/php/php-src/pull/1699

Just bringing this back up to the top because of the recent influx in internals
activity. I'm hoping to put this to vote tomorrow, so if anyone has any
questions or problems with this RFC, then please let me know!

Thanks for pushing that improvement forward, Tom.

AIUI, digit separators are stripped during lexing, so

echo 1_000;

will print

1000

I think it is important to explicitly note that in the RFC.

With regard to "stringy numerics": besides the potential BC break, IMHO
there is no need to support digit separators for string literals at all,
because that could easily be provided by a userland function. Maybe
it's worth pointing that out in the RFC.

--
Christoph M. Becker