220 20826 article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Rough Draft Proposal of Interpolated String Literals Date: Sat, 26 Sep 2015 07:34:12 -0700 (PDT) Lines: 288 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/mixed; boundary="----=_Part_665_245841195.1443278052270" X-Trace: ger.gmane.org 1443278057 24729 80.91.229.3 (26 Sep 2015 14:34:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Sep 2015 14:34:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBZOZTKYAKGQEKLN5KZQ@isocpp.org Sat Sep 26 16:34:17 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZfqYK-0006GG-Mx for gclcip-std-proposals@m.gmane.org; Sat, 26 Sep 2015 16:34:17 +0200 Original-Received: by iofb144 with SMTP id b144sf228860885iof.1 for ; Sat, 26 Sep 2015 07:34:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=uqyKF05YZenoNBkqnjuN877bhIL3EejSzr43V7yJ6EE=; b=G2JGiMKlV375kjyHVr4I+dhlOnE+IqK8ek5+CwbhSpOq4CcTsg/9rzeEKbwPFILiz0 PpmN/G6rhMIGcEdq/vnB71RGePwjCq8+s6ktq/XCTYnQCYO7lUryDE72mef6u2iB/xZD bcytC8kGuP6aA4e/lT+xA811XOUlBwh3FJ5u+g1tjDNt22epXE7boVw+bikQn077swRJ zC7Nle5LkM/vhpZGKpFa3zKRQC423PYz/mYwxncTIegAeo9bWC+9y3y6aIGuJNfEG9en hB+N1dhBd4mSzptdmBKSi90TXV/OHH6U32MvrWM+WfUGESAJ+Sx+OvI+tVrCu3LXpz9V FupA== X-Gm-Message-State: ALoCoQkCknyhcyrmCW8irN+yvVL4QUHtXqn0UvHvdt7IE7pLedujNVsomZtdD+tS/3nyzmhVrPpo X-Received: by 10.182.20.195 with SMTP id p3mr9641017obe.28.1443278055100; Sat, 26 Sep 2015 07:34:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.138.133 with SMTP id qq5ls460073igb.35.canary; Sat, 26 Sep 2015 07:34:13 -0700 (PDT) X-Received: by 10.50.43.230 with SMTP id z6mr83706igl.9.1443278053759; Sat, 26 Sep 2015 07:34:13 -0700 (PDT) In-Reply-To: <6e2f4cfa-92d7-49e3-ad1a-5b0e0bb803b9@isocpp.org> X-Original-Sender: bengt.gustafsson@beamways.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:20826 Archived-At: ------=_Part_665_245841195.1443278052270 Content-Type: multipart/alternative; boundary="----=_Part_666_1906696658.1443278052271" ------=_Part_666_1906696658.1443278052271 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In addition: By providing the formatting as part of the string rather than= =20 the embedded expressions translation gets a chance to change the formatting= =20 details. Using functions like octal(x) prevents this from being done=20 without changing the source code. 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= =20 > be able to send the formatting string to it. You can't do that to a=20 > operator. > > Obviously formatting information must be cryptic (printf) or verbose=20 > (cout), we can't have neither. My idea was more towards cryptic of course= ,=20 > but it does not need to be as cryptic as printf... > > The idea of destroying the flow of reading you created by introducing F""= =20 > in the first place by putting the formatting afterwards seems really=20 > awkward to me. Then I like the idea of octal(x) or hex(x) better although= I=20 > wonder how it would scale to > multiple formatting commands. Also the std namespace gets a lot of new=20 > names which could be used better, and some we would use like precision ar= e=20 > already used by ostream, aren't they? Or can they be reused maybe? > > To preserve performance these functions would have to return some=20 > descriptor object which I think is Tony's intention. > > Personally I'm more for cryptic than verbose now that we have to choose.= =20 > We have all toiled to learn the strange details and shortcomings of the= =20 > printf formatting, by thinking a little before designing a new terse synt= ax=20 > I think we can do much better. Here is a starting point from one project = of=20 > 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=20 > with zeros on the left. > // t Use (one character) as the thousand separator, inserted= =20 > 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= =20 > instead of a fixed width. m without a number is treated as an infinite=20 > maximum width. > // f Prefer normal float formatting. > // e Force e format. > // a Show All decimals. This forces trailing zeros to be added until the= =20 > decimals or precision of a number is satisfied. > > > > Den m=C3=A5ndag 21 september 2015 kl. 21:08:22 UTC+2 skrev Andrew Tomazos= : >> >> >> >> On Mon, Sep 21, 2015 at 6:11 PM, Tony V E wrote: >> >>> >>> >>> On Sun, Sep 20, 2015 at 10:55 PM, Andrew Tomazos = =20 >>> wrote: >>> >>>> OK, here is what I have got for formatting: >>>> >>>> Each embedded expression in an interpolated string literal, may=20 >>>> optionally have a positive integer associated with. To make such an=20 >>>> association, the index is placed between the introducer and the embedd= ed=20 >>>> 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=20 >>>> octal." {std::hex, std::oct} >>>> >>> >>> >>> F"$ The register is $reg in decimal, $hex(reg) in hex, and $octal(reg)= =20 >>> in octal." >>> >>> where hex() and octal() are normal functions (either returning string o= r=20 >>> 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=20 >> ${octal(reg)} in octal." >> >> and this would work as proposed, however when the format specifiers get= =20 >> longer and include precision, padding, showbase, etc, etc - their verbos= ity=20 >> begins to obfuscate the expression that they appertain to, hence why I= =20 >> propose to provide a mechanism to index them as auxillary expressions an= d=20 >> 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,= =20 >> $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=20 >> expressions. It is easy to see how this is useful. >> >> There is also a performance issue with having the formatting inline as= =20 >> you suggest. A function hex that takes a string and returns a string wo= uld=20 >> perform a heap allocation of the hex string and then as a second step=20 >> interpolate it into the interpolated string. By having the formatting= =20 >> separate this enables iostreams (or other interpolated string consuming= =20 >> libraries) to stream the data directly to hex, without the intermediate= =20 >> value. This is the same concept as iostreams. >> >> --=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/. ------=_Part_666_1906696658.1443278052271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In addition: By providing the formatting as part of the st= ring rather than the embedded expressions translation gets a chance to chan= ge the formatting details. Using functions like octal(x) prevents this from= being done without changing the source code.


Den tisdag 22 sep= tember 2015 kl. 09:18:19 UTC+2 skrev Bengt Gustafsson:
Ok, I was unclear there. The reaso= n for the separate function name was to be able to send the formatting stri= ng to it. You can't do that to a operator.

Obviously= formatting information must be cryptic (printf) or verbose (cout), we can&= #39;t have neither. My idea was more towards cryptic of course, but it does= not need to be as cryptic as printf...

The idea o= f destroying the flow of reading you created by introducing F"" i= n 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 although 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 are already used by ostream, aren't they? Or c= an they be reused maybe?

To preserve performance t= hese 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 lea= rn the strange details and shortcomings of the printf formatting, by thinki= ng a little before designing a new terse syntax I think we can do much bett= er. Here is a starting point from one project of mine:

=
// d<decimals> Number of decimals for floating point= numbers.
// p<precis= ion> Precision for floating or = int numbers.
// w<wid= th> Min width in characters. V= alue is left aligned.
//= r<width> Min width in char= acters. Value is right aligned.
= // c<width> Min wid= th in characters. Value is centered.
// z<width> Mi= n width in characters. Value is right aligned and padded with zeros on the = left.
// t<sep> Use <sep> (one character) as = the thousand separator, inserted every third digit in front of the decimal = char.
// ; Use decimal char from locale for floating poi= nt numbers.
// . Use dot as decimal char.
// , = Use comma as decimal char.
// m<maxwidth> = Max field width. I.e. width is treated as a minimum width instead of a fixe= d width. m without a number is treated as an infinite maximum width.
<= div> // f Prefer normal float formatting.
// e F= orce e format.
// a Show All decimals. This forces trail= ing zeros to be added until the decimals or precision of a number is satisf= ied.



Den m=C3=A5ndag 21 s= eptember 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, Sep 20, 2= 015 at 10:55 PM, Andrew Tomazos <a= ndrew...@gmail.com> wrote:
OK, here is what I have got for formatting:

Each embe= dded expression in an interpolated string literal, may optionally have a po= sitive integer associated with. To make such an association, the index is p= laced between the introducer and the embedded expression, and separated fro= m the embedded expression by a colon:

=C2=A0 F&quo= t;$ The register is $reg in decimal, $1:reg in hex, and $2:reg in octal.&qu= ot; {std::hex, std::oct}


F"= ;$ The register is $reg in decimal, $hex(reg) in hex, and $octal(reg) in oc= tal."

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

Assumin= g 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 p= roposed, however when the format specifiers get longer and include precisio= n, padding, showbase, etc, etc - their verbosity begins to obfuscate the ex= pression 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 fo= otnotes).

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 the formatt= ing information can be shared amongst multiple embedded expressions.=C2=A0 = It is easy to see how this is useful.

There is als= o a performance issue with having the formatting inline as you suggest.=C2= =A0 A function hex that takes a string and returns a string would perform a= heap allocation of the hex string and then as a second step interpolate it= into the interpolated string.=C2=A0 By having the formatting separate this= enables iostreams (or other interpolated string consuming libraries) to st= ream the data directly to hex, without the intermediate value.=C2=A0 This i= s 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-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>.
------=_Part_666_1906696658.1443278052271-- ------=_Part_665_245841195.1443278052270-- .