Subject: bug#59531: 29.0.50: An alternative to `string-to-number` which throws an error (or returns a NIL value) when input is non-parseable as number

From: Robert Pluim <[email-masked]>
Date: Wed, 14 Dec 2022 17:40:24 +0100

>>>>> On Thu, 24 Nov 2022 10:00:06 +0200, Eli Zaretskii <[email-masked]> said:

    >> This return value is not very helpful.  The choice of a number ZERO
    >> as "Not A Number" doesn't help one to distinguish between the
    >> following two cases
    >> 
    >> (1) Input was a valid number, and it parses to number zero
    >> 
    >> (2) Input was NOT a valid number, and it was forcibly reported as ZERO
    >> 
    >> Consider amending `string-to-number` to throw an error (or return
    >> NIL) when the input is not parseable as a number, or providing an
    >> alternative API to validate numbers.  I am trying to parse some
    >> fields in an org table, and see if the field value is a number or
    >> not;

    Eli> Thanks.

    Eli> Changing the default behavior to signal an error is out of the question,
    Eli> since this is used in the Lisp reader and elsewhere, all over the place.  It
    Eli> is very useful there.

    Eli> However, as an enhancement, we could have an additional optional argument to
    Eli> request that the function signal an error if the string cannot be parsed as
    Eli> a number.

`cl-parse-integer' already has such an argument, but it only works for
integers. Alternatively, you could use `read-from-string' and check if
it returns something of type `integer' or `float'.

Robert
--