I share the same concerns as Rowan Collins
From my reading of Rowan's email, he was making a general point that
new features can have a cost of added complexity for users. He then
clarified "I don't personally think that applies here".
I'm really not a fan of the RFC in general. Also I think those kind
of magic numbers should be constants with meaningful names, and it
that case you could just compute them by adding powers of ten.
E.g. DISCOUNT_IN_CENTS = 1 * 10^5 + 3 * 10^4 + 5 * 10^3;
Actually I think this example highlights why numeric literal
separators can be very helpful for improving readability and
preventing mistakes. First, which of these is faster to read?
$discount = 1 * 10**5 + 3 * 10**4 + 5 * 10**3;
$discount = 135_00;
Secondly, your example of adding powers of 10 is off by an order
of magnitude! It's equivalent to $1,350.00, not $135.00, but this
isn't very obvious when reading the complex expression.
Of course, if you prefer the first approach you can continue using it.
But personally I find the second approach quicker to read and less
prone to mistakes.
Moreover I feel that people may misread numbers like that if people
use different groupings. E.g. 1_0000_0000_0000; by skimming rapidly
I could think it's a billion(10^6) when in reality it's a trillion
(10^9). Even if maybe some countries are moving away from the
grouping digits in groups of 4.
Even with the different grouping, it's faster for me to count the
digits in that number than if it had no separator at all.
I'll probably vote against it but that's only my opinion.
That's up to you. But even if you don't personally have a need for
the feature, I think it's worth considering that there are valid use
cases for it which can help improve code readability and clarify intent.