[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59531: 29.0.50: An alternative to `string-to-number` which throws an
From: |
Robert Pluim |
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 |
Date: |
Wed, 14 Dec 2022 17:40:24 +0100 |
>>>>> On Thu, 24 Nov 2022 10:00:06 +0200, Eli Zaretskii <eliz@gnu.org> 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
--
- 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,
Robert Pluim <=