220 20543 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: Mon, 21 Sep 2015 04:55:40 +0200 Lines: 270 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=047d7b874e504962a3052039042f X-Trace: ger.gmane.org 1442804143 4121 80.91.229.3 (21 Sep 2015 02:55:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 02:55:43 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBD5KHQXXWYPRBLPD7WXQKGQETQKLZFI@isocpp.org Mon Sep 21 04:55:43 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f197.google.com ([209.85.217.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZdrGY-0005E8-Tc for gclcip-std-proposals@m.gmane.org; Mon, 21 Sep 2015 04:55:42 +0200 Original-Received: by lbot4 with SMTP id t4sf33834602lbo.0 for ; Sun, 20 Sep 2015 19:55:42 -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=qAJGBrMRNpj7+1LPBbIRycIztCJAgaODAmgV1PfUFNE=; b=j0xmGL0II1Lo3h2wGXDdhz0KtAvZcYGTtKIKJ0qsvJpf4StXbhECbm0fKiC8CKQNu4 XuhCgcvHcrrC+SSeogeiuyvBWMntHgN+5tEJ3GIHh1J/7BhwlhVW8CRoXhr5FMocTcti mJpckQ7RrN3ygtvqD4LK2Ua8qibVXAvmYVYEj7c9n1ARrv6h7SEQ2fas8wzFa7VUJnmH kE8m472/VdfByZ2MG1OYdD8tmYGy9gkp6dN740GBe1DxnJZ2ZH5vXFe9LLqb4LXD9/K1 1pgyrqtgDEH7GCXfVige7jKbSbellJI/93g7v2fwh5/3fORMKtARgyRrLeMzq3O6LKIV SpIQ== X-Gm-Message-State: ALoCoQkqjZj6tWo23FyLw4Vb5X7+547ReELQdBzE/gJdu52zB/hapsQRkUH6NTpY0Zo+llbdwa/4 X-Received: by 10.112.198.33 with SMTP id iz1mr2766403lbc.8.1442804142388; Sun, 20 Sep 2015 19:55:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.86.39 with SMTP id m7ls601356wiz.23.gmail; Sun, 20 Sep 2015 19:55:40 -0700 (PDT) X-Received: by 10.194.82.167 with SMTP id j7mr20539563wjy.123.1442804140926; Sun, 20 Sep 2015 19:55:40 -0700 (PDT) Original-Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com. [2a00:1450:400c:c05::232]) by mx.google.com with ESMTPS id n8si14311725wiz.102.2015.09.20.19.55.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2015 19:55:40 -0700 (PDT) Received-SPF: pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::232 as permitted sender) client-ip=2a00:1450:400c:c05::232; Original-Received: by wicgb1 with SMTP id gb1so95934068wic.1 for ; Sun, 20 Sep 2015 19:55:40 -0700 (PDT) X-Received: by 10.195.11.3 with SMTP id ee3mr19951508wjd.89.1442804140694; Sun, 20 Sep 2015 19:55:40 -0700 (PDT) Original-Received: by 10.28.73.137 with HTTP; Sun, 20 Sep 2015 19:55:40 -0700 (PDT) In-Reply-To: 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::232 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:20543 Archived-At: --047d7b874e504962a3052039042f Content-Type: text/plain; charset=UTF-8 OK, here is what I have got for formatting: Each embedded expression in an interpolated string literal, may optionally have a positive integer associated with. To make such an association, the index is placed between the introducer and the embedded expression, and separated from the embedded expression by a colon: F"$ The register is $reg in decimal, $1:reg in hex, and $2:reg in octal." {std::hex, std::oct} If any associated index appears in the interpolated string literal then: 1. Let us define M as the index with the highest integer value. 2. For each index between 1 and M, there must be at least one embedded expression with that associated index. (There may be more than one) 3. A braced-init-list of length M shall follow the interpolated string literal. It's contents are known as auxiliary expressions. The associated indexes and values of these auxiliary expressions are stored in the std::interpolated_string. The operation of the standard library operator<<(ostream&, std::interpolated_string), when interpolating an embedded expression with an associated index is: 1. Save the state of the ostream 2. ostream << associated expression 3. ostream << the embedded expression 4. Restore the state of the ostream The standard library conversion of std::interpolated_string to std::string has the same effect (as if the string was interpolated with ostringstream). The rationale of using an indexed system for the formatting information and keeping it separate is that it is not an essential part of reading the interpolated string literal. On a left-to-right pass of the interpolated string literal you can get the essential information (the fixed substrings and embedded expressions), and then the bulky and less interesting auxillary information (the formatting details) are presented at the end. Much the same way as we would present footnotes in a natural language document. On Mon, Sep 21, 2015 at 2:27 AM, Jim Porter wrote: > On 9/20/2015 4:43 PM, Andrew Tomazos wrote: > >> 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. >> > > For me, that makes this a non-starter, since my primary issue with I/O > streams is how verbose the manipulators are. As you say, there's about a > 10-character overhead for default-formatted interpolations, but that's > nothing compared to the overhead for making a number use hexademical, or > changing floating point precision. If you're using these manipulators > inside functions, then it becomes quite painful to manage without Boost's > I/O state savers[1]. > > Both categories are inferior to: >> >> print(F"% The number of %goods is %count."); // 4 >> >> [snip] > >> 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. >> > > I disagree that (4) is the most readable, except for very simple examples. > The closest I've seen to ideal (for my purposes) is how str.format() works > in Python. C++ can't support all the niceties that str.format() has (unless > named-arguments ever get added to C++), but even without that, I think I'd > prefer that style. > > In my experience, the point when printing something out becomes a bother > is when I'm either a) printing the results of expressions (that I don't > want to add a local variable for), or b) when I need to print things with > non-default formatting. If neither of those are true, then using the << > operator is usually plenty readable to me, if slightly more verbose than > necessary. > > For cases (a) and (b), I think Python-style format strings are the easiest > to follow; I can quickly see what each placeholder is (either by index, or > by name for complex format strings), and what it'll be formatted like. I > actually prefer the format string to *exclude* the actual expressions that > it interpolates over since it lets me ignore them when I'm trying to figure > out how I'd like a line of text to be formatted. > > There are other niceties to doing this as a library feature, since it > would be easy to pull format strings from, say, localization files. While > such a library feature might not be appropriate for everyone's localization > needs, it would probably be sufficient for relatively-simple cases. > > - Jim > > [1] http://www.boost.org/doc/libs/1_55_0/libs/io/doc/ios_state.html > > > -- > > --- 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. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7b874e504962a3052039042f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, here is what I have got for formatting:

=
Each embedded expression in an interpolated string literal, may option= ally have a positive integer associated with. To make such an association, = the index is placed between the introducer and the embedded expression, and= separated from the embedded expression by a colon:

=C2=A0 F"$ The register is $reg in decimal, $1:reg in hex, and $2:re= g in octal." {std::hex, std::oct}

If any asso= ciated index appears in the interpolated string literal then:
1. Let us define M as the index with the highest integer value.=

= 2. For each index between 1 and M, there must be at least one embedded expr= ession with that associated index. =C2=A0(There may be more than one)
=

3. A braced= -init-list of length M shall follow the interpolated string literal.=C2=A0 = It's contents are known as auxiliary expressions.

The associated indexes and = values of these auxiliary expressions are stored in the std::interpolated_s= tring.

The operation of the standard library operator<<(ostream&, std::= interpolated_string), when interpolating an embedded expression with an ass= ociated index is:

1. Save the state of the ostream
2. ostream << associated expression
3. ostream << the embedded expression
4. Restore the state of the ostream

<= /div>
The standard library conversion of std::int= erpolated_string to std::string has the same effect (as if the string was i= nterpolated with ostringstream).

=
The rationale of using an indexed system for the= formatting information and keeping it separate is that it is not an essent= ial part of reading the interpolated string literal.=C2=A0 On a left-to-rig= ht pass of the interpolated string literal you can get the essential inform= ation (the fixed substrings and embedded expressions), and then the bulky a= nd less interesting auxillary information (the formatting details) are pres= ented at the end.=C2=A0 Much the same way as we would present footnotes in = a natural language document.

On Mon, Sep 21, 2015 at 2= :27 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
On 9/20/2015 4:43 PM, Andrew Tomazos w= rote:
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.

 For me, that makes this a non-starter, since my primary issue with I/O stre= ams is how verbose the manipulators are. As you say, there's about a 10= -character overhead for default-formatted interpolations, but that's no= thing compared to the overhead for making a number use hexademical, or chan= ging floating point precision. If you're using these manipulators insid= e functions, then it becomes quite painful to manage without Boost's I/= O state savers[1].

Both categories are inferior to:

=C2=A0 =C2=A0print(F"% The number of %goods is %count."); // 4
[snip]
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.=C2=A0 I claim 4 is significantly more readable than the others.

 I disagree that (4) is the most readable, except for very simple examples. = The closest I've seen to ideal (for my purposes) is how str.format() wo= rks in Python. C++ can't support all the niceties that str.format() has= (unless named-arguments ever get added to C++), but even without that, I t= hink I'd prefer that style.

In my experience, the point when printing something out becomes a bother is= when I'm either a) printing the results of expressions (that I don'= ;t want to add a local variable for), or b) when I need to print things wit= h non-default formatting. If neither of those are true, then using the <= < operator is usually plenty readable to me, if slightly more verbose th= an necessary.

For cases (a) and (b), I think Python-style format strings are the easiest = to follow; I can quickly see what each placeholder is (either by index, or = by name for complex format strings), and what it'll be formatted like. = I actually prefer the format string to *exclude* the actual expressions tha= t it interpolates over since it lets me ignore them when I'm trying to = figure out how I'd like a line of text to be formatted.

There are other niceties to doing this as a library feature, since it would= be easy to pull format strings from, say, localization files. While such a= library feature might not be appropriate for everyone's localization n= eeds, it would probably be sufficient for relatively-simple cases.

- Jim

[1] http://www.boost.org/doc/libs/1_5= 5_0/libs/io/doc/ios_state.html
<= br>
--

--- You received this message because you are subscribed to the Google Grou= ps "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.c= om/a/isocpp.org/group/std-proposals/.

--

---
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>.
--047d7b874e504962a3052039042f-- .