220 20845 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: Sat, 26 Sep 2015 23:09:41 +0200 Lines: 317 Approved: news@gmane.org Message-ID: References: <043C43B5-72C9-4136-8D2F-2A3D745B2975@gmail.com> <6e2f4cfa-92d7-49e3-ad1a-5b0e0bb803b9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b874e50fb31230520ace18a X-Trace: ger.gmane.org 1443301796 24254 80.91.229.3 (26 Sep 2015 21:09:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Sep 2015 21:09:56 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBD5KHQXXWYPRBFMTTSYAKGQENGVVGBQ@isocpp.org Sat Sep 26 23:09:56 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f197.google.com ([209.85.212.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zfwj1-0000R6-8u for gclcip-std-proposals@m.gmane.org; Sat, 26 Sep 2015 23:09:43 +0200 Original-Received: by wicgb1 with SMTP id gb1sf22784716wic.3 for ; Sat, 26 Sep 2015 14:09: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=id9MJWZEQ5qgM12P0Oap6IZnjM0UVblOOHolS+G3p0I=; b=frio8SmlOeZFp10YcfRsIebFNc7dHUzlass8Mp0WtUpTAbp+JdiFKvqsEveKpJh/3S 0ZMzhbsF1cSWogDVeQHGqQABD658AD8rNim9vIBONoly0qKu0WeLQ6T9O5SbFxnnklvZ edTMoGt8A1FMrpTBHlJTa+M6uE9TJt3+dg1DU+WWHdwCVrR9vr3oN75nW/SGUxGVLSgV B5531F7EB4Bk2oGR/jpC9pQmtd1Kk24Hh6iSNhEmXJdpF+0GQeWO7s2qrjQJL3675g/E eBJzmVZaMezkj/sKszqYCZXfC/E1ICYTiA62x+fqYSI9hr57RgeK5X9m15+kKIN9g37X 3PUA== X-Gm-Message-State: ALoCoQn5J/GG07diyE1U4lFheEmzelrsb57hQyhBShDLQwMB7ZFo8Om+MnbtkA5l1QYpT6n1Txj1 X-Received: by 10.112.125.104 with SMTP id mp8mr2009185lbb.20.1443301782519; Sat, 26 Sep 2015 14:09:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.35.34 with SMTP id e2ls311062wij.34.canary; Sat, 26 Sep 2015 14:09:41 -0700 (PDT) X-Received: by 10.194.103.103 with SMTP id fv7mr15776839wjb.152.1443301781529; Sat, 26 Sep 2015 14:09:41 -0700 (PDT) Original-Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com. [2a00:1450:400c:c05::22c]) by mx.google.com with ESMTPS id ar8si12161213wic.37.2015.09.26.14.09.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Sep 2015 14:09:41 -0700 (PDT) Received-SPF: pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::22c as permitted sender) client-ip=2a00:1450:400c:c05::22c; Original-Received: by wicge5 with SMTP id ge5so60089268wic.0 for ; Sat, 26 Sep 2015 14:09:41 -0700 (PDT) X-Received: by 10.195.11.3 with SMTP id ee3mr13084956wjd.89.1443301781350; Sat, 26 Sep 2015 14:09:41 -0700 (PDT) Original-Received: by 10.28.73.137 with HTTP; Sat, 26 Sep 2015 14:09:41 -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::22c 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:20845 Archived-At: --047d7b874e50fb31230520ace18a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Sep 26, 2015 at 4:34 PM, Bengt Gustafsson < bengt.gustafsson@beamways.com> wrote: > In addition: By providing the formatting as part of the string rather tha= n > the embedded expressions translation gets a chance to change the formatti= ng > details. Using functions like octal(x) prevents this from being done > without changing the source code. > Interesting thought, but I don't think this comes up. It is my understanding that translation sometimes reorders the embedded expressions, but does not change their content or formatting. > > Den tisdag 22 september 2015 kl. 09:18:19 UTC+2 skrev Bengt Gustafsson: >> >> Ok, I was unclear there. The reason for the separate function name was t= o >> be able to send the formatting string to it. You can't do that to a >> operator. >> >> Obviously formatting information must be cryptic (printf) or verbose >> (cout), we can't have neither. My idea was more towards cryptic of cours= e, >> but it does not need to be as cryptic as printf... >> >> The idea of destroying the flow of reading you created by introducing F"= " >> in the first place by putting the formatting afterwards seems really >> awkward to me. Then I like the idea of octal(x) or hex(x) better althoug= h I >> wonder how it would scale to >> multiple formatting commands. Also the std namespace gets a lot of new >> names which could be used better, and some we would use like precision a= re >> already used by ostream, aren't they? Or can they be reused maybe? >> >> To preserve performance these functions would have to return some >> descriptor object which I think is Tony's intention. >> >> Personally I'm more for cryptic than verbose now that we have to choose. >> We have all toiled to learn the strange details and shortcomings of the >> printf formatting, by thinking a little before designing a new terse syn= tax >> I think we can do much better. Here is a starting point from one project= of >> mine: >> >> // d Number of decimals for floating point numbers. >> // p Precision for floating or int numbers. >> // w Min width in characters. Value is left aligned. >> // r Min width in characters. Value is right aligned. >> // c Min width in characters. Value is centered. >> // z Min width in characters. Value is right aligned and padded >> with zeros on the left. >> // t Use (one character) as the thousand separator, inserted >> every third digit in front of the decimal char. >> // ; Use decimal char from locale for floating point numbers. >> // . Use dot as decimal char. >> // , Use comma as decimal char. >> // m Max field width. I.e. width is treated as a minimum width >> instead of a fixed width. m without a number is treated as an infinite >> maximum width. >> // f Prefer normal float formatting. >> // e Force e format. >> // a Show All decimals. This forces trailing zeros to be added until the >> decimals or precision of a number is satisfied. >> >> >> >> Den m=C3=A5ndag 21 september 2015 kl. 21:08:22 UTC+2 skrev Andrew Tomazo= s: >>> >>> >>> >>> On Mon, Sep 21, 2015 at 6:11 PM, Tony V E wrote: >>> >>>> >>>> >>>> On Sun, Sep 20, 2015 at 10:55 PM, Andrew Tomazos >>>> wrote: >>>> >>>>> 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 embed= ded >>>>> 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} >>>>> >>>> >>>> >>>> F"$ The register is $reg in decimal, $hex(reg) in hex, and $octal(reg) >>>> in octal." >>>> >>>> where hex() and octal() are normal functions (either returning string >>>> or some magic like a pair(format, value). >>>> ? >>>> >>> >>> Assuming the existence of such functions you could write: >>> >>> F"$ The register is $reg in decimal, ${hex(reg)} in hex, and >>> ${octal(reg)} in octal." >>> >>> and this would work as proposed, however when the format specifiers get >>> longer and include precision, padding, showbase, etc, etc - their verbo= sity >>> begins to obfuscate the expression that they appertain to, hence why I >>> propose to provide a mechanism to index them as auxillary expressions a= nd >>> place them at the back (like footnotes). >>> >>> Also note they can repeat so: >>> >>> std::cout << F"$ The registers are ($spi, $pc) in decimal, ($1:spi, >>> $1:pc) in hex, and ($2:spi, $2:pc) in octal." {std::hex, std::oct}; >>> >>> So the formatting information can be shared amongst multiple embedded >>> expressions. It is easy to see how this is useful. >>> >>> There is also a performance issue with having the formatting inline as >>> you suggest. A function hex that takes a string and returns a string w= ould >>> perform a heap allocation of the hex string and then as a second step >>> interpolate it into the interpolated string. By having the formatting >>> separate this enables iostreams (or other interpolated string consuming >>> libraries) to stream the data directly to hex, without the intermediate >>> value. This is the same concept as iostreams. >>> >>> -- > > --- > 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/. > --=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/. --047d7b874e50fb31230520ace18a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Sep 26, 2015 at 4:34 PM, Bengt Gustafsson <bengt.gustafsso= n@beamways.com> wrote:
In addition: By providing the formatting as part of the string= rather than the embedded expressions translation gets a chance to change t= he formatting details. Using functions like octal(x) prevents this from bei= ng done without changing the source code.

=
Interesting thought, but I don't think this comes up.=C2=A0 It is = my understanding that translation sometimes reorders the embedded expressio= ns, but does not change their content or formatting.
=C2=A0
=

Den tisdag 22 september 2015 kl. 09:18:19 UTC+2 skrev Bengt Gustafsson= :
Ok, I was unclear= there. The reason for the separate function name was to be able to send th= e formatting string to it. You can't do that to a operator.

Obviously formatting information must be cryptic (printf) or verbos= e (cout), we can't have neither. My idea was more towards cryptic of co= urse, but it does not need to be as cryptic as printf...

The idea of destroying the flow of reading you created by introducin= g F"" in the first place by putting the formatting afterwards see= ms really awkward to me. Then I like the idea of octal(x) or hex(x) better = although I wonder how it would scale to
multiple formatting comma= nds. Also the std namespace gets a lot of new names which could be used bet= ter, and some we would use like precision are already used by ostream, aren= 't they? Or can they be reused maybe?

To prese= rve performance these functions would have to return some descriptor object= which I think is Tony's intention.

Personally= I'm more for cryptic than verbose now that we have to choose. We have = all toiled to learn the strange details and shortcomings of the printf form= atting, by thinking a little before designing a new terse syntax I think we= can do much better. Here is a starting point from one project of mine:

//= d<decimals> Number of = decimals for floating point numbers.
// p<precision> Precision for floating or int numbers.
// w<width> Min width in characters. Value is left aligned.
<= div> // r<width> Min width in characters. Value is r= ight aligned.
// c&= lt;width> Min width in ch= aracters. Value is centered.
// z<width> = Min width in characters. Value is right aligned and padded with zeros on th= e left.
// t<sep= > Use <sep> (one ch= aracter) as the thousand separator, inserted every third digit in front of = the decimal char.
/= / ; Use decimal char from l= ocale for floating point numbers.
// . Use dot= as decimal char.
/= / , Use comma as decimal ch= ar.
// m<maxwidt= h> Max field width. I.e. w= idth is treated as a minimum width instead of a fixed width. m without a nu= mber is treated as an infinite maximum width.
// f Prefer normal float formatting.
// e Forc= e e format.
// a Show All decimals. This force= s trailing zeros to be added until the decimals or precision of a number is= satisfied.



Den m=C3=A5nd= ag 21 september 2015 kl. 21:08:22 UTC+2 skrev Andrew Tomazos:


On Mon, Sep 21, 2015 at 6:11 PM, Tony V E <tvan...@gmail.com> wrote:


On Sun, Se= p 20, 2015 at 10:55 PM, Andrew Tomazos <andrew...@gmail.com> wrote:
OK, here is what I have got for formatting:

Ea= ch embedded expression in an interpolated string literal, may optionally ha= ve a positive integer associated with. To make such an association, the ind= ex is placed between the introducer and the embedded expression, and separa= ted from the embedded expression by a colon:

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

<= br>F"$ The register is $reg in decimal, $hex(reg) in hex, and $octal(r= eg) in octal."

where hex() and octal() are normal fu= nctions (either returning string or some magic like a pair(format, value).<= br>?

Assuming the existence of such functions you could write:

<= /div>
F"$ The register is $reg in decimal, ${hex(reg)} in hex, and= ${octal(reg)} in octal."

and this would = work as proposed, however when the format specifiers get longer and include= precision, padding, showbase, etc, etc - their verbosity begins to obfusca= te the expression that they appertain to, hence why I propose to provide a = mechanism to index them as auxillary expressions and place them at the back= (like footnotes).

Also note they can repeat so:

=C2=A0 =C2=A0 std::cout << F"$ The = registers are ($spi, $pc) in decimal, ($1:spi, $1:pc) in hex, and ($2:spi, = $2:pc) in octal." {std::hex, std::oct};

So th= e formatting information can be shared amongst multiple embedded expression= s.=C2=A0 It is easy to see how this is useful.

The= re is also a performance issue with having the formatting inline as you sug= gest.=C2=A0 A function hex that takes a string and returns a string would p= erform a heap allocation of the hex string and then as a second step interp= olate it into the interpolated string.=C2=A0 By having the formatting separ= ate this enables iostreams (or other interpolated string consuming librarie= s) to stream the data directly to hex, without the intermediate value.=C2= =A0 This is the same concept as iostreams.

--

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