220 36858 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Fri, 9 Feb 2018 22:37:19 +0000 Lines: 289 Approved: news@gmane.org Message-ID: References: <356d5835-f1bf-4699-94f5-0b2d3d0b9c0e@isocpp.org> <1731062.NdW3nXAon1@tjmaciei-mobl1> <14112472.AvYaaQfdXc@tjmaciei-mobl1> <32bedcad-92df-4d63-98ed-8f05c558cab7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f4f5e808d750db41bb0564cf2b96" X-Trace: blaine.gmane.org 1518215756 24932 195.159.176.226 (9 Feb 2018 22:35:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 22:35:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBIOF7DJQKGQE7OZKVMY@isocpp.org Fri Feb 09 23:35:52 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekHGH-0004Ex-17 for gclcip-std-proposals@m.gmane.org; Fri, 09 Feb 2018 23:35:17 +0100 Original-Received: by mail-oi0-f70.google.com with SMTP id j68sf4585681oih.14 for ; Fri, 09 Feb 2018 14:37:22 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1518215842; cv=pass; d=google.com; s=arc-20160816; b=z9lCp7wiaqquvGazCQqQpN7VdonIVJriLiyoHczr3qsvvE9HT1lTRfOIFlN+Msecb5 tsw8oL9aR8G9M4G5MXF6smrol5hjF1DTL3dm2lf0esPzCQ3sPJAKvWlQAGc5CPeJwC/7 t+P4EKZVG48hx0Q03CaAftN+I1i4QL8whxt/kWDdoZNAW7PKGAafHlHIL5dzU0Bd6Z9t MUERxBwd1GBsayJpuopusvTpB4vIhD4sGGyAIeHCNFAp/Ni+hGTpJe0L+QvLkAQ9/vVq 7ukp9+z4UO6PK4OIXuuUzsMc9jmI1vkOF2Tgps6f019hQ6omqVyQeaVdWhkjH6ApgnpG 7dZA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=CjQaPeIM3IMsh1m+V4Yr7FcjoFc/livWFRwu2fCnCUo=; b=OTReLTAliUTwUcRvPk+mU+HSWj1RXc6i2Oqd6RA0L8brLwu5tjOPDF66mapNJxPzoR Jgpwb2OHPeBzy8z1EwNiDkRdXuCM1o4ONfnqPJoBOSRWF65kFfmRlDv3aQQrKoTf3ruW KBw6dJ5ojyy9lnG+ohWB9G7/qpKy7uv/jT7IxQUE+gGUuL1AFODlcIUmxaQhXUqeVDSo 0LeOIXxy0EbDmu1fR9NIXlX2+O77LSM3LsPQYgchh+MXjiT1zllvCcRq5j0H1C8scFEH w8yjmPrE4DKa36qZrtAt8kavkVKoG8ifv0XMYU1+NbPTb4GXx3ukzw4QC2uRcaQkK/On zYKA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OEeq575F; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=CjQaPeIM3IMsh1m+V4Yr7FcjoFc/livWFRwu2fCnCUo=; b=hiFmw7iaiLCXV+XfnHdmRhljgW117pLrNw+/he3x8RcBSAORdt7Mji4bKLGwlfZNOg JiiI7tp6XuwsYDd2tsrwfh4HBw8qoVgBa+AZwtTVDlc34caINTlMqqDL731HldnF+zYd G85c7tiRR/VRCebj038jT2EUB+j3Pqp0xpW9tJFr3L4sfOxVvoWHHq9qqAakmjInfFno uXafGEZhknLShASHdXy5yI7Ev1jnl+rJFoVw45NZ723KMGcdKiD3Urqvd5Y5btyHwx50 EbET8o5Ud/lrECAGBEcXm4INA9iVrYpjZEni/c0nT/4CBUPx8b4HS7mRIE2qac1BQDqK W/Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=CjQaPeIM3IMsh1m+V4Yr7FcjoFc/livWFRwu2fCnCUo=; b=rBIpXh+dJpxPj3zfK+wJOq+LVbS1ddct4wdNg19bwJmT8kVQnjO0Gz9QiRr/OpcFoD N+bbo4cGsBdgSz39OgXrLOM2yRcVnDqxBi8KFBPXoU0+BPJzGUsfUIQvppVB8DLND9ax l43KjPzI+dxrkefmAi/ychHQ4NgVpBOMeenA3ZnHEL7We6KGTwY3DQbA1+Y3wgtftsm8 SXSnr6AVMdO71DPOcCip/DdHoNUAJhby5CjHVcqMs9e78boBghGqrpF16rVAvwl1/SpE StAbPaUTlSWGlqZ1BsDIPNW1Ygqauhhm1UcJYqN1VVDLCAhZOri7AcRDpUHvTdkkBiZa GOTg== X-Gm-Message-State: APf1xPD9NVhm7X3rlzBCJK496Te9pUsnvhHu3dYbI/AfxvwbWT8YGb/6 8x0t4X5WCHTfy3SgZfh1I7lCpw== X-Google-Smtp-Source: AH8x225kD4scVpGWm0bs4c3rutV5AUej6NQWYgRSuV8ZD1s+GbkyZDqW1NxNCo4gYvD4aeIZ3MdcZg== X-Received: by 10.157.45.37 with SMTP id v34mr2523383ota.47.1518215842167; Fri, 09 Feb 2018 14:37:22 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.19.2 with SMTP id e2ls969714oii.14.gmail; Fri, 09 Feb 2018 14:37:20 -0800 (PST) X-Received: by 10.202.85.204 with SMTP id j195mr2654464oib.99.1518215840916; Fri, 09 Feb 2018 14:37:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518215840; cv=none; d=google.com; s=arc-20160816; b=q4dzghN95ysP9mF199oZ4J5tks1WTLUqaLmU4HyOB3vUjTSk9O+7ZhwcudxMlZW6bt xyBTewSoEIpKA0BANBuN3vVYxdMt9gbJXRXummPFN8HbBMCNCeCqhNOKzy7Lxv2Msv1I +7q5/zfOxOumGCJbCjMH5OdM8FdsIx3LSB5KJZSJ/G3aVURfbleHO1Ezx9iTw6N6bL9r U5kM2TWUy6/8ynZHqob8UEPDsIvT410K9o9ApojiPECOyVe/RJdPKiCxdIa41hOGKcNU e40xPo2jgW3A4t6yll38pIXT3j1tZ1MnkZjR58jXf0qxwZ99fCOR1C32R79+Bs4Zw+KQ 5pzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=Y32ldFU8Jd8PE29HeC/Gn7HFZzEXZKjr1Ilm5zx4R/A=; b=S7mJbx9zwKVKWrwFHgwwmiwZZ3ZC6eMaGFAfXLlBLdZYUbk9RTFom5FCK/xWcbNSGN sB3ITPOcTuDzvr6zqlkOK7GX/NjDOkL+bOl33pKbvug9XPN3H8iy98PIafGBQFckV0jm u9cj98B/72WpiLGiG/8Rz37VdLOYxnvx4oqxn1Y9pu1F+4VLpcdRH9jG+ocIP3I2byVK 3dDbNBm/+s3DETO9+H7uWFrv/i3Zorm8P5aj7XfPSJP612qkC+GUxRfabztOL6q99241 hkVPbwWfsjmY/7G5oyyr+TFcK4s0Qg07ZkOBnHiZRA6ZmNTNun1Zf5T4YXQkVepe11l/ soSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OEeq575F; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id t65sor1397140oig.166.2018.02.09.14.37.20 for (Google Transport Security); Fri, 09 Feb 2018 14:37:20 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.202.27.3 with SMTP id b3mr3011803oib.91.1518215840348; Fri, 09 Feb 2018 14:37:20 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Fri, 9 Feb 2018 14:37:19 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Fri, 9 Feb 2018 14:37:19 -0800 (PST) In-Reply-To: <32bedcad-92df-4d63-98ed-8f05c558cab7@isocpp.org> X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OEeq575F; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:36858 Archived-At: --f4f5e808d750db41bb0564cf2b96 Content-Type: text/plain; charset="UTF-8" Yep, understood. My aim was to get a discussion rolling, and my idea was to communicate my idea through a way that is clear as day. Now the idea is communicated, and the retaliation being that streams are viewed as the Satan's rectum of C++, the constructive part can start. And it has. I appreciate your advice about the seriousness in which one should approach a proposal. Let's do ourselves a favour and move on from the original implementation idea and on to the possibilities that have opened up from other users. The last thing we need is such ideas being swallowed up in discussion of an expired implementation idea. On 9 Feb 2018 22:00, "Nicol Bolas" wrote: > On Friday, February 9, 2018 at 8:51:31 AM UTC-5, Jake Arkinstall wrote: >> >> On 9 Feb 2018 08:24, "Thiago Macieira" wrote: >> >> On Friday, 9 February 2018 00:05:44 PST Richard Hodges wrote: >> > It's a great idea. Naysayers talk of performance concerns as a result of >> > virtual functions. These are irrelevant. >> > >> > Firstly, the cost of turning numeric values into strings far outweighs >> the >> > cost of a virtual call >> >> That depends on a lot. The cost of a virtual call could easily get to 5% >> total >> time of a conversion, which is non-negligible, if there's no memory >> allocation >> involved. >> >> >> 5% during a debug stage is no big deal. I set the scene for a good >> reason: not all code is production code. >> > > So... you want to add a language feature that you know up-front ought not > be used in production code? No, the committee should not spend time on > things like that. Not when there are genuine deficiencies in the language > that matter for actual production code. > > We shouldn't be making language features that "production code" should > avoid. We should be making "production code" *easier to write*. > > My focus here is making C++ friendlier until performance is a goal. >> > > Again, you start from the presumption that "performance" and > "friendliness" are diametrically opposed. I see nothing about writing > conversion functions that require "unfriendliness". Just because it isn't > the iostreams garbage doesn't make it unfriendly; just *new*. > > There is absolutely no reason, that I can see, to treat early development >> with the same fine-tooth comb as the final product. >> > > Early development code often *becomes* code in the final product. I've > seen it happen in many projects. You write something quick and dirty, with > the expectation that you'll refactor it later or something. But you never > get the chance to actually do so; there are too many actually important > things to be getting on with. So the bad code sits there. > > > Second, fixing iostream to make it more efficient is a separate concern. >> >> More than likely, doing that means replacing it entirely, which in turn >> means >> this feature cannot depend on iostreams. It must be generic, if it exists >> at >> all. >> >> >> That would be nice, but generic is a royal pain in the backside in this >> circumstance. >> > > Then make it *not* be "a royal pain in the backside." Put forth a design > that doesn't have these pain points. > > Simply declaring that it won't work without investigating the > possibilities is defeatist. *Especially* since we're now on the cusp of > having compile-time string manipulation in the language. I know that's not > enough to do what you're talking about, but the existence of such a thing > means that the idea is not beyond the realm of possibility. > > >> This is not something that can be written in the current language because >> it requires interpetation of the strings. >> > > There are three aspects to this proposal: 1) the parsing of a string > literal into sections of the literal and object names, 2) the conversion of > each object name into a string, and 3) the concatenation of those bits of > strings into the final string. Obviously, steps 2 and 3 can be rather > interrelated. > > >> How on earth that is supposed to generalise to choices of fmt, string >> conversion and concatenation, stringstreams, and whatever magical solution >> we're waiting on to make string manipulation efficient, I have no idea, >> especially in the general situation where the different approaches - e.g. >> to_string and operator<< - are not equivalent. >> > > That's the thing with proposals. If you're serious about it, you *find* > ways to solve the problems. > > Your proposal's biggest problem is that it binds a rightfully-maligned > library construct to a language construct, thereby *permanently* affixing > it into people's code, to the point where said language construct will be > avoided by people who actually care about performance. You even acknowledge > that this is a problem by saying that it's not for "production code". Why > should we add language features that production code should avoid? > > The other thing is that you don't have to generalize the solution to be > able to work with any conversion system. The problem is not that you've > picked a *particular* library solution. It's that you've picked a *bad* > particular library solution. > > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit https://groups.google.com/a/ > isocpp.org/d/msgid/std-proposals/32bedcad-92df-4d63- > 98ed-8f05c558cab7%40isocpp.org > > . > -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOEw3aZAH1tB4hKeZyVWKG%2BHiGybyvGk5X1PehdY0aBHg%40mail.gmail.com. --f4f5e808d750db41bb0564cf2b96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yep, understood. My aim was to get a discussion rolling, = and my idea was to communicate my idea through a way that is clear as day. = Now the idea is communicated, and the retaliation being that streams are vi= ewed as the Satan's rectum of C++, the constructive part can start. And= it has. I appreciate your advice about the seriousness in which one should= approach a proposal.

Let'= s do ourselves a favour and move on from the original implementation idea a= nd on to the possibilities that have opened up from other users. The last t= hing we need is such ideas being swallowed up in discussion of an expired i= mplementation idea.

On 9 Feb 2018 22:00, "Nicol Bolas" <jmckesson@gmail.com> wrote:
On Friday, Febru= ary 9, 2018 at 8:51:31 AM UTC-5, Jake Arkinstall wrote:
= On 9 Feb 2018 08:24, "Thiago Macieira" <th= i...@macieira.org> wrote:
On = Friday, 9 February 2018 00:05:44 PST Richard Hodges wrote:
> It's a great idea. Naysayers talk of performance concerns as a res= ult of
> virtual functions. These are irrelevant.
>
> Firstly, the cost of turning numeric values into strings far outweighs= the
> cost of a virtual call

That depends on a lot. The cost of a virtual call could easily get to= 5% total
time of a conversion, which is non-negligible, if there's no memory all= ocation
involved.

5% during a debug stage is no big deal. I set the scene for = a good reason: not all code is production code.

So... you want to add a language feature that you know up-front ought= not be used in production code? No, the committee should not spend time on= things like that. Not when there are genuine deficiencies in the language = that matter for actual production code.

We shouldn't be making l= anguage features that "production code" should avoid. We should b= e making "production code" easier to write.

<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
= My focus here is making C++ friendlier until performance is a goal.

Again, you start from the presumption that "= performance" and "friendliness" are diametrically opposed. I= see nothing about writing conversion functions that require "unfriend= liness". Just because it isn't the iostreams garbage doesn't m= ake it unfriendly; just new.

There is absolutely no re= ason, that I can see, to treat early development with the same fine-tooth c= omb as the final product.

Early developmen= t code often becomes code in the final product. I've seen it hap= pen in many projects. You write something quick and dirty, with the expecta= tion that you'll refactor it later or something. But you never get the = chance to actually do so; there are too many actually important things to b= e getting on with. So the bad code sits there.

> Second, fixing iostream to make it more efficient is a separate concer= n.

More than likely, doing that means replacing it entirely, which in tu= rn means
this feature cannot depend on iostreams. It must be generic, if it exists a= t
all.

That would be nice, but generic is a royal pain in the backside in th= is circumstance.

Then make it not b= e "a royal pain in the backside." Put forth a design that doesn&#= 39;t have these pain points.

Simply declaring that it won't work= without investigating the possibilities is defeatist. Especially si= nce we're now on the cusp of having compile-time string manipulation in= the language. I know that's not enough to do what you're talking a= bout, but the existence of such a thing means that the idea is not beyond t= he realm of possibility.
=C2=A0
This is not something that can be = written in the current language because it requires interpetation of the st= rings.

There are three aspects to this pro= posal: 1) the parsing of a string literal into sections of the literal and = object names, 2) the conversion of each object name into a string, and 3) t= he concatenation of those bits of strings into the final string. Obviously,= steps 2 and 3 can be rather interrelated.
=C2=A0
How on earth tha= t is supposed to generalise to choices of fmt, string conversion and concat= enation, stringstreams, and whatever magical solution we're waiting on = to make string manipulation efficient, I have no idea, especially in the ge= neral situation where the different approaches - e.g. to_string and operato= r<< - are not equivalent.

That's= the thing with proposals. If you're serious about it, you find = ways to solve the problems.

Your proposal's biggest problem is t= hat it binds a rightfully-maligned library construct to a language construc= t, thereby permanently affixing it into people's code, to the po= int where said language construct will be avoided by people who actually ca= re about performance. You even acknowledge that this is a problem by saying= that it's not for "production code". Why should we add langu= age features that production code should avoid?

The other thing is t= hat you don't have to generalize the solution to be able to work with a= ny conversion system. The problem is not that you've picked a partic= ular library solution. It's that you've picked a bad par= ticular library solution.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit = https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/32be= dcad-92df-4d63-98ed-8f05c558cab7%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOEw3= aZAH1tB4hKeZyVWKG%2BHiGybyvGk5X1PehdY0aBHg%40mail.gmail.com.
--f4f5e808d750db41bb0564cf2b96-- .