Am 14.01.2019 um 18:15 schrieb William F Pokorny:
> Suppose my question was too whether we should consider the 3.7/3.8
> behavior broken - you seem to be saying it was.
Let's put it this way: Going by the reference docs on numeric
expressions - specifically FLOAT_LITERAL - the v3.7 behaviour would have
to be considered broken, unless interpreting the syntax in a
The key question is under what circumstances a sequence of characters
that matches the production rules of FLOAT_LITERAL, followed by some
other character that does not fit in, constitutes a broken
FLOAT_LITERAL, as opposed to a valid FLOAT_LITERAL token immediately
followed by the next token.
The v3.6 behaviour can easily be interpreted as consistently treating
such cases as valid, but erroneously implementing MANTISSA as:
DIGIT... [DECIMAL_POINT | [DIGIT2...] |
DIGIT | DECIMAL_POINT
The v3.7 behaviour must be interpreted as treating such cases as broken
if the non-matching character is a dot, but valid if it is any other
character. That's a pretty arbitrary distinction.
The (new) v3.8 behaviour consistently treats all such cases as valid
again, while implementing MANTISSA as documented.
> Folks can again cause parsing to separate values by using extra decimal
> points in numeric strings. Has me wondering what might happen with typos
> like 1..2 (not tried it).
That would have to be `1.` followed by `.2`.
> Or where we specify lists of values separated
> by commas or not. Can the latter get scrambled in ways that are confusing?
Dots don't constitute valid infix or postfix operators in numeric
expressions, so there's no ambiguity there.
Post a reply to this message