220 20536 article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Rough Draft Proposal of Interpolated String Literals Date: Sun, 20 Sep 2015 23:43:32 +0200 Lines: 211 Approved: news@gmane.org Message-ID: References: <043C43B5-72C9-4136-8D2F-2A3D745B2975@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bb04db007c1ea052034a816 X-Trace: ger.gmane.org 1442785415 10608 80.91.229.3 (20 Sep 2015 21:43:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Sep 2015 21:43:35 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBD5KHQXXWYPRBBOR7SXQKGQEK5MN3GA@isocpp.org Sun Sep 20 23:43:35 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZdmOU-0002FH-PD for gclcip-std-proposals@m.gmane.org; Sun, 20 Sep 2015 23:43:34 +0200 Original-Received: by lbbmp1 with SMTP id mp1sf32692167lbb.2 for ; Sun, 20 Sep 2015 14:43:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type: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=W7fRiu+UisfMvx+EYoZRBqeCVombfwPSUHN9p14Ze3E=; b=mhLJZ+P/n6ZY3wHmtl9BeVyB+G3JUBXFBfgTC8PBbFgs0qqSuzQAe/ESNXfXzZvlEl Se646Xid4+EoJ7rd4eInVWZnk8qY/idfnm9RQOD/mmbbwl/Ha0acjq+Mh3NY52TCCVtC j+0JfjZkE5uVV3CaipXy3Zz/ww5RQpfgk+WqUW4g+nOJXWX2DW2lP45UrMIOqineb8pH dkRbBdcSouy9xvHPuluhL56W0n1fUPHmf8ceJzF9Y6h5jjT1l0CvElu+mG3xR/m5b6Ix J2KyGvd7pq8M3lPKi4I+h+Vw9aApQHucwukr51vGza8qz7K8tljEW39Xt2C/c4+mnjfH gcSA== X-Gm-Message-State: ALoCoQnHyeDm2z/e0H+BxCo5oUuW76329LjnaIVlP8DexQxZRNbJe2WzL7TE+rZH9rAJmjikpXLi X-Received: by 10.152.6.201 with SMTP id d9mr2684270laa.6.1442785414243; Sun, 20 Sep 2015 14:43:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.100.233 with SMTP id fb9ls558302wib.26.canary; Sun, 20 Sep 2015 14:43:33 -0700 (PDT) X-Received: by 10.195.11.40 with SMTP id ef8mr13882078wjd.103.1442785413265; Sun, 20 Sep 2015 14:43:33 -0700 (PDT) Original-Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com. [2a00:1450:400c:c05::235]) by mx.google.com with ESMTPS id sa20si27093322wjb.117.2015.09.20.14.43.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2015 14:43:33 -0700 (PDT) Received-SPF: pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::235 as permitted sender) client-ip=2a00:1450:400c:c05::235; Original-Received: by wicfx3 with SMTP id fx3so88257130wic.0 for ; Sun, 20 Sep 2015 14:43:33 -0700 (PDT) X-Received: by 10.194.80.38 with SMTP id o6mr19369692wjx.52.1442785413020; Sun, 20 Sep 2015 14:43:33 -0700 (PDT) Original-Received: by 10.28.73.137 with HTTP; Sun, 20 Sep 2015 14:43:32 -0700 (PDT) In-Reply-To: <043C43B5-72C9-4136-8D2F-2A3D745B2975@gmail.com> X-Original-Sender: andrewtomazos@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::235 as permitted sender) smtp.mailfrom=andrewtomazos@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE 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:20536 Archived-At: --047d7bb04db007c1ea052034a816 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Sep 20, 2015 at 11:14 PM, Miro Knejp wrote: > > > On 20 Sep 2015, at 22:58 , Jim Porter wrote: > > > > On 9/18/2015 3:21 PM, Andrew Tomazos wrote: > >> Please find attached a very very rough draft of a proposal entitled > >> "Interpolated String Literals". > >> > >> Mainly after encouragement or discouragement, and any high-level > >> thoughts you might have about it. > > > > I'm not sure it's *really* necessary to do this as a language extension= , > rather than just as a library. Granted, there are nice aspects of doing i= t > as a language feature (you can use expressions in-place and they get > expanded as you'd expect), but given the choice, I think I'd rather see > something like printf. That could be done as a library-only addition, and > would make it fairly easy for folks to design a similar interface with > slightly-different syntax if they had different needs. > > > > The specification also doesn't seem to say anything about the part that > I think is most important for format specifiers: formatting options. I/O > streams' manipulators are a pain to use, since they're verbose, and unlik= e > printf, they don't turn themselves off in most cases; hence why Boost add= ed > I/O state savers. I'd much rather see a proposal that improves format > specifiers. However, I think a proposal for this would end up looking mor= e > like printf's placeholder-style, since it seems fairly difficult to add > format specifiers to an in-place style (at least, if you want to maintain > readability). > If you need format specifiers or a runtime-provided format string then > string interpolation is not the tool you=E2=80=99re looking for. String > interpolation does not replace formatting and vice versa. String > interpolation is used when the tokenization and formatting rules are > determined at compile time, where it is a convenient syntax to replace a > bunch of function or operator call boilerplate. > I'd like to add formatting to the proposal without damaging the major use case (where expressions are interpolated with the default formatting for their type), but I don't see a good way yet. There is no good way to place embedded expressions in a string literal as proposed, without core language changes. The only current two categories of way to do this as a library feature is is to either: A. List the substrings and embedded expressions as separate expressions, separated by a delimiter token: print << "The number of " << goods << " is " << count << "."; // 1 print("The number of ", goods, " is ", count, "."); // 1 B. Put the expressions at the end: print("% The number of % is %.", goods, count); // 2 print("% The number of %1 is %2.", goods, count); // 2 print("% The number of %goods is %count.", "goods", goods, "count", count); // 3 Both categories are inferior to: print(F"% The number of %goods is %count."); // 4 The reason 4 is superior to 1 is that it is far more readable. This is because there is far less noise around the embedded expressions. The reason 4 is superior to 2 is that the reader requires mental indirections between the format string and the expression list. The reader has to jump back and forth between them to understand what is going on. With 4 the string can be read from left-to-right in one pass. The reason 4 is superior to 3 is that in 3 the final map is redundant information that clutters the code, requires maintenance, and isn't checked by the compiler. While the library solutions are not that bad, my claim is that the use case is so extremely popular, that even a slightly better syntax for it justifies a core solution. I claim 4 is significantly more readable than the others. --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --047d7bb04db007c1ea052034a816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 20, 2015 at 11:14 PM, Miro Knejp <miro.knejp@gmail.com<= /a>> wrote:

> On 20 Sep 2015, at 22:58 , Jim Porter <jvp4846@g.rit.edu> wrote:
>
> On 9/18/2015 3:21 PM, Andrew Tomazos wrote:
>> Please find attached a very very rough draft of a proposal entitle= d
>> "Interpolated String Literals".
>>
>> Mainly after encouragement or discouragement, and any high-level >> thoughts you might have about it.
>
> I'm not sure it's *really* necessary to do this as a language = extension, rather than just as a library. Granted, there are nice aspects o= f doing it as a language feature (you can use expressions in-place and they= get expanded as you'd expect), but given the choice, I think I'd r= ather see something like printf. That could be done as a library-only addit= ion, and would make it fairly easy for folks to design a similar interface = with slightly-different syntax if they had different needs.
>
> The specification also doesn't seem to say anything about the part= that I think is most important for format specifiers: formatting options. = I/O streams' manipulators are a pain to use, since they're verbose,= and unlike printf, they don't turn themselves off in most cases; hence= why Boost added I/O state savers. I'd much rather see a proposal that = improves format specifiers. However, I think a proposal for this would end = up looking more like printf's placeholder-style, since it seems fairly = difficult to add format specifiers to an in-place style (at least, if you w= ant to maintain readability).
If you need format specifiers or a runtime-provided format string th= en string interpolation is not the tool you=E2=80=99re looking for. String = interpolation does not replace formatting and vice versa. String interpolat= ion is used when the tokenization and formatting rules are determined at co= mpile time, where it is a convenient syntax to replace a bunch of function = or operator call boilerplate.

=
I'd like to add formatting to the proposal w= ithout damaging the major use case (where expressions are interpolated with= the default formatting for their type), but I don't see a good way yet= ..

Ther= e is no good way to place embedded expressions in a string literal as propo= sed, without core language changes.

The only current two categories of way to do = this as a library feature is is to either:
=
A.=C2=A0 List the substrings and embed= ded expressions as separate expressions, separated by a delimiter token:

=C2=A0 = =C2=A0print << "The number of " << goods << &qu= ot; is " << count << "."; =C2=A0// 1
=C2=A0 =C2=A0print("The number of ", goods, = " is ", count, "."); =C2=A0// 1

B. Put the expressions at the= end:

=
=C2=A0 =C2=A0print("% The number of % is %.= ", goods, count); =C2=A0// 2
=C2= =A0 =C2=A0print("%=C2=A0The number of %1 is %2.", goods, count); = // 2
=C2=A0 =C2=A0print("%=C2=A0= The number of %goods is %count.", "goods", goods, "coun= t", count); // 3

Both categories are inferior= to:

=C2=A0 print(F"% The number of %goods is %count."= ); // 4

The reason 4 is superior to 1 is that it is far more readable.=C2=A0= This is because there is far less noise around the embedded expressions.

=
Th= e reason 4 is superior to 2 is that the reader requires mental indirections= between the format string and the expression list.=C2=A0 The reader has to= jump back and forth between them to understand what is going on.=C2=A0 Wit= h 4 the string can be read from left-to-right in one pass.

The reason 4 is s= uperior to 3 is that in 3 the final map is redundant information that clutt= ers the code, requires maintenance, and isn't checked by the compiler.<= /span>
W= hile the library solutions are not that bad, my claim is that the use case = is so extremely popular, that even a slightly better syntax for it justifie= s a core solution.=C2=A0 I claim 4 is significantly more readable than the = others.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7bb04db007c1ea052034a816-- .