From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3259 invoked from network); 3 Aug 2023 21:30:41 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 21:30:41 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id CF61841691; Fri, 4 Aug 2023 07:30:37 +1000 (AEST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by minnie.tuhs.org (Postfix) with ESMTPS id 16C3541690 for ; Fri, 4 Aug 2023 07:30:32 +1000 (AEST) Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2b9fa64db41so22931991fa.1 for ; Thu, 03 Aug 2023 14:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691098230; x=1691703030; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ScBtQ6rli78wwbltJhOIJZnnzuk/iB+UgsHMYedyg+U=; b=eOReMiyFEGmHTfisST+CeeOsjllQ3xubuysM9hD4ZDHX0JxY0ezzUHFiab77HCXVVW /b2LOScC1ftDfliOdxHM7ZSFMF+Pqm6yW7z/p73aXx1OHtNFpxwVjSLeo8MTcusgay4Q uKGd8RfpV38vr75bz65gMmBRAKsjT7XTP03lvwPlbYKteyrhWqm7Mo9bt/9RHpyOoJCu 2FIvN4ir4fReKrDCOifsbj5y+riiy5h1DK5ILJIyad9/feTXKlIaRt4OdBFSCVt8uAlb 9k6ghZ/2g9uKjOWpmLOoCwzwTwA7MkDb0X2czfUIBrU6c2Lf3/m20cH14QkRM5AeyYpe FYNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691098230; x=1691703030; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ScBtQ6rli78wwbltJhOIJZnnzuk/iB+UgsHMYedyg+U=; b=hDDG9n5IrdKTYWYu6N923aYV174aeT543PiSX2ZPbOhDCEuC/D9EKKvXVZmbyRNZwK IoZzoig7V75VcXXGCswbayRhM5xAJSE8JvauF09MCd9tW6pt9rPIJv56s/z50tJoadNM J3s++BXg++VrHs3VF0WPAmsvlr8nfpxzfjAsvxdKmqnBqKhEUa8TFGb+E2rX5FF4QL1k ozwgErhovhA6WuTmf1zi0WFiq67U3QGfFcGS2p/z/FKONcuLdd+ntw+fDMD5V/98/p53 jP4XjXtMK+iaGprRi70h8sWNAucmKBydk/6yokPsc6YO+HZh7tTZlVyfNa/53qJIkoGA HibA== X-Gm-Message-State: AOJu0Yz9HdkqfokKf4OWecI+kEF45n15arisPhiEQVGs/vbFFL1j12As KPrs1EWEE1DdmUnUdQ2/GBiTGaxuaaf+fELHuQA8luRF X-Google-Smtp-Source: AGHT+IF9fILRk5xr6yqqJElpuePSGd/askw+tD2nNv5sSv/C2BAY0V2yMibFmbnwf3iclqkrCJgy1Y0rUwY4wjPG6GA= X-Received: by 2002:a2e:8706:0:b0:2b9:35ae:c9ac with SMTP id m6-20020a2e8706000000b002b935aec9acmr23002lji.2.1691098229587; Thu, 03 Aug 2023 14:30:29 -0700 (PDT) MIME-Version: 1.0 References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> In-Reply-To: From: Dan Cross Date: Thu, 3 Aug 2023 17:29:53 -0400 Message-ID: To: Alejandro Colomar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 24D6BCGLTV5QCQINWG446476JAIWB4UW X-Message-ID-Hash: 24D6BCGLTV5QCQINWG446476JAIWB4UW X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: [TULSA] Re: python List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Aug 3, 2023 at 2:05=E2=80=AFPM Alejandro Colomar wrote: > On 2023-08-03 19:51, John Cowan wrote: > > On Thu, Aug 3, 2023 at 1:29=E2=80=AFPM Alejandro Colomar > > wrote: > > > > But if speed is not a problem, I'd keep the good ol' syntax that > > > > everybody knows. No need to make everybody learn a "cool" new print > >> function, that probably won't be as tunable as printf(3) is. > >> > >> > > By that argument, there would be no C, only Algol 68 and PL/I, or subse= ts > > of them. > > > > I didn't claim that there's never a reason to invent new syntax. My clai= m > was rather that in this case, there isn't. > > - printf(3) is more powerful than any other existing formatting function > that I know of any language --I'm still curious of what's the equivale= nt > of "%+'0#8.5f" in other formatting functions--. One issue is that this isn't standard C: the `'` verb for grouping by thousands is an SUSv2 extension. I just checked the latest C23 draft, and unless I missed it, it doesn't appear to have made it in. But things like that are fairly straight-forward in many other languages. For example, in Go, the format string is nearly identical, modulo the `'`: : prithvi; cat print.go package main import "fmt" func main() { fmt.Printf("%+0#8.5f\n", 3.1415) } : prithvi; go run print.go +3.14150 : prithvi; Type safety is achieved through reflection. In Rust, which has a very pleasant formatted print facility, type safety is handled by implementing `print` and `println` as macros. I don't miss `printf` there. > - It is also reasonably fast (at least for such a highly-customizable > formatting function), and I'd like to see any system beat that while > keeping the customizability. At Google, a group of exceptionally talented engineers wrote a replacement in C++ for both type safety and because, bluntly, `printf` (actually `snprintf`) was too slow. I believe the overall mechanism made it into ABSL. > - It is type-safe, with the right tools. No it's not, and it really can't be. True, there are linters that can try to match up types _if_ the format string is a constant and all the arguments are known at e.g. compile time, but C permits one to construct the format string at run time (or just select between a bunch of variants); the language gives you no tools to enforce type safety in a meaningful way once you do that. > I can understand the need for less-customizable faster formatting functio= ns > for very-high-performance programs, and std::format may fit well there. = But > other than that, I don't see a reason to invent so many different formatt= ing > functions. Of course, one may do that just for fun, in which case I appl= aud > that. But printf(3) is superior to them, IMO. That sort of relative value judgement can be difficult to justify without specifying the criteria that goes into one's judgement. As you said, it is an opinion and that's fine, but opinions vary. :-) - Dan C.