From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs 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 Message-ID: <87zgbqndl3.fsf@gmail.com> References: <838rk0ye7t.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30580"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59531@debbugs.gnu.org, Ramesh Nedunchezian To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 14 17:41:38 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p5Up7-0007lV-T7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Dec 2022 17:41:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5Uoa-0002s4-Fh; Wed, 14 Dec 2022 11:41:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p5UoZ-0002rc-2u for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 11:41:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p5UoY-0007aM-RH for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 11:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p5UoY-00053A-F5 for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 11:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Dec 2022 16:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59531 X-GNU-PR-Package: emacs Original-Received: via spool by 59531-submit@debbugs.gnu.org id=B59531.167103603619398 (code B ref 59531); Wed, 14 Dec 2022 16:41:02 +0000 Original-Received: (at 59531) by debbugs.gnu.org; 14 Dec 2022 16:40:36 +0000 Original-Received: from localhost ([127.0.0.1]:40279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5Uo7-00052o-VC for submit@debbugs.gnu.org; Wed, 14 Dec 2022 11:40:36 -0500 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:35772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5Uo4-00052e-4Z for 59531@debbugs.gnu.org; Wed, 14 Dec 2022 11:40:34 -0500 Original-Received: by mail-wr1-f49.google.com with SMTP id y16so333107wrm.2 for <59531@debbugs.gnu.org>; Wed, 14 Dec 2022 08:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=klk4ZCuXOWoEWC2NNdIp1BKxM1ymLeJMCrgWYD1ZFDY=; b=VsawYg6B8646LgBzRQ9cW/oaA+9X/4MBVjKwj+xqkPvIwig5BvPrNlihjh+mtPqY5c ITWBaxpO0Pg/FUX+Q4vOeQTtzoJ3/pi0+mEwB6/rRDYKdnulgMXrBTnmJYNHrO+kEo73 X5CWg2ofl8kxEJ8oGX2xoI0g9MyykPQWePn9Hv0KJR89DjxD14wdqAvmrPh8tcXC27Ok X8l+AkX+YiL8m2YcTqhHuzuoLi4Fb2lVSUfX+6Oii7XE7XsP3PDTQ7/VyeNqFgycJs/p oCndrcmROLpnhhNoJ5pvyXo5nFUivGxHqA9OGwS2+JDCosM4m7kSij08SLPR2REZOCVD 7sqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=klk4ZCuXOWoEWC2NNdIp1BKxM1ymLeJMCrgWYD1ZFDY=; b=nOTFG2Nel0Oo4TBvBeCB7saVQr1HxRofaAx/vCuv+KbqETpmKKVgqdszzXwW7D1q5l /AOWI1Ijk7R2Rtx/BX5YS2g9lFKNfXfEYPLwuI5QDufjmeueyrFQ5GMMCAFpodTV4vRR 9CVdppJeBG7hOVglDGlaENj6cwkoxdHAhohyl+psf5z41gbwiVvmblIxFZkR4Vmnd3b+ YSOIc6pxA5nmqX1KGPaWAygXzIfRTvFB914Jtd5j+vEaFKj50FpkN57OLWXySaON1D8j 2TYf+leaQzhjaRhs+gAKVGs1Mh8M5OlbBJM91pf/QYHkL9/iPa+l88WZfz4H2ACA13BC I3ig== X-Gm-Message-State: ANoB5pnJVRqEX0Yt0JEFpdSIGkLLs3Ij/mObY3gJJzwU3cJKhimpgLt0 7Acwljjsq2ByphjvBw/0kgIjwMXlMJM= X-Google-Smtp-Source: AA0mqf5v7JkLPWUlnwGrUGpW+rXBwHoirjFYNGFejxZEKEtrHtmkVIsOiu0Hf7YB/L3nz91O2A0f1A== X-Received: by 2002:adf:dc89:0:b0:242:55fe:e055 with SMTP id r9-20020adfdc89000000b0024255fee055mr17077327wrj.66.1671036025681; Wed, 14 Dec 2022 08:40:25 -0800 (PST) Original-Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id l1-20020adfa381000000b002423a5d7cb1sm3287132wrb.113.2022.12.14.08.40.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Dec 2022 08:40:25 -0800 (PST) In-Reply-To: <838rk0ye7t.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 24 Nov 2022 10:00:06 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250968 Archived-At: >>>>> On Thu, 24 Nov 2022 10:00:06 +0200, Eli Zaretskii said: >> This return value is not very helpful.=C2=A0 The choice of a number = ZERO >> as "Not A Number" doesn't help one to distinguish between the >> following two cases >>=20 >> (1) Input was a valid number, and it parses to number zero >>=20 >> (2) Input was NOT a valid number, and it was forcibly reported as ZE= RO >>=20 >> 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.=C2=A0 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 que= stion, 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 a= rgument 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 --=20