220 4411 article Path: news.gmane.org!not-for-mail From: Jonathan Wakely Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: std::putf now supports %N%, like Boost.Format Date: Tue, 14 May 2013 12:09:55 -0700 (PDT) Lines: 138 Approved: news@gmane.org Message-ID: References: <66ac5a48-8d1a-41f3-92ac-085c3b7de87a@isocpp.org> <75cd8f0a-81be-40d5-84a5-69287b3b18e2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_471_7255459.1368558595448" X-Trace: ger.gmane.org 1368558599 24724 80.91.229.3 (14 May 2013 19:09:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 May 2013 19:09:59 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMONUNYS4IRBBEYZKGAKGQEZRX2OUY@isocpp.org Tue May 14 21:09:58 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UcKbm-0000Xs-7d for gclcip-std-proposals@m.gmane.org; Tue, 14 May 2013 21:09:58 +0200 Original-Received: by mail-qa0-f72.google.com with SMTP id i13sf1415672qae.11 for ; Tue, 14 May 2013 12:09:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=6vB6Ebfgns7nLigOBvDB+3x/8TTFnxCWnTZUWmOnN28=; b=DtiWJyvQj2UpO3RN2CpBlfMQ7/6oZAVkdeClh+wOca2Az7vzMQq5zbhMeEmgA3wbKe J+aXg/6o17yzYgDikhRdsuxvnTGaf9G4QWeFKffOVHLNxMkzMuIgPaeEbaphRvrOfCYx h8xqTRxBfkI8IOovbTJ+pYS/TbC2stDE5NUOb+nvn/a6lsNbrPk6EyiIdU2rpjF2cpgX /fUKr19tCY+K+CGwIDsq4wAidSSm3m9RS7P9dkmg8HnD69iNrZV5laJku77POq6yCzBe nJC4/T/DYipk0aRggVenbJcqSQSW3cVEcz6ZeBFe7JNytUdzNBdZpEVwQd2lYARztpWO p/kQ== X-Received: by 10.236.81.115 with SMTP id l79mr18153897yhe.20.1368558597088; Tue, 14 May 2013 12:09:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.107.70 with SMTP id ha6ls415435qeb.81.gmail; Tue, 14 May 2013 12:09:55 -0700 (PDT) X-Received: by 10.49.12.67 with SMTP id w3mr2577567qeb.27.1368558595806; Tue, 14 May 2013 12:09:55 -0700 (PDT) In-Reply-To: <75cd8f0a-81be-40d5-84a5-69287b3b18e2@isocpp.org> X-Original-Sender: cxx@kayari.org Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:4411 Archived-At: ------=_Part_471_7255459.1368558595448 Content-Type: text/plain; charset=ISO-8859-1 On Monday, May 13, 2013 10:39:30 PM UTC+1, Nicol Bolas wrote: > > On Monday, May 13, 2013 10:14:42 AM UTC-7, Jonathan Wakely wrote: >> >> On Friday, May 10, 2013 2:19:25 AM UTC+1, Nicol Bolas wrote: >> >>> >>> Speaking of N3506, how did that proposal fare at the committee meeting? >>> >> >> I wasn't in the room for the discussion but the straw polls showed no >> consensus for adding putf() with only printf-style formatting, strong >> opposition to adding non-printf-style formatting to putf, and unanimous >> support for "a separate format string paper that is not constrained by >> printf" >> > > Wait. So they *don't* want "non-printf-style formatting". > Some people did not want a std::putf() with printf-style formatting *and* non-printf extensions. i.e. if it is based on printf it should support *only* printf formatting and nothing else. > But they *do* want "a separate format string paper that is not > constrained by printf". How does that make sense? > People would rather see something entirely different to printf, not something based on printf. I don't think those two views conflict. > > So no support for adding this, partly because with variadic templates the >> conversion specifier after the % is redundant, the stream knows the type >> anyway. Strong support for something else using a different syntax such as >> {} and move away from printf style. >> > > Why exactly do they want to move away from printf syntax? I understand > about the formatting specifier issue, but I see no reason to use `{}` over > the well-known `%` syntax. Is it just to appease C# users? > What's the point of %s vs. %d? In the typesafe printf example in http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html the conversion specifier is completely ignored, you can say printf("%s %d", 1, "two") and it works correctly. So if you don't need the conversion specifier to DTRT then why use it? A new proposal doesn't have to use {}, it could use %1, %2 etc. or something else. I happen to like Python's format string syntax, although obviously expecting "{first} {second}".format(make_pair(1,2)) in C++ is unrealistic! -- --- 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/?hl=en. ------=_Part_471_7255459.1368558595448 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Monday, May 13, 2013 10:39:30 PM UTC+1, Nicol Bolas wrote:On Monday, May 13, 2013 10:14:42 AM = UTC-7, Jonathan Wakely wrote:
On Fri= day, May 10, 2013 2:19:25 AM UTC+1, Nicol Bolas wrote:

Speaking of N3506, how did that proposal fa= re at the committee meeting?

I wasn't in the= room for the discussion but the straw polls showed no consensus for adding= putf() with only printf-style formatting, strong opposition to adding non-= printf-style formatting to putf, and unanimous support for "a separate form= at string paper that is not constrained by printf"

Wait. So they don't want "non-printf-style formatting".=

Some people did not want a std::putf() with printf-st= yle formatting *and* non-printf extensions.  i.e. if it is based on pr= intf it should support *only* printf formatting and nothing else.
 =
But they do= want "a separate format string paper that is not constrained by printf". H= ow does that make sense?

People would rather= see something entirely different to printf, not something based on printf.=

I don't think those two views conflict. 

 
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">

So no support for adding this, partly because = with variadic templates the conversion specifier after the % is redundant, = the stream knows the type anyway.  Strong support for something else u= sing a different syntax such as {} and move away from printf style.

Why exactly do they want to move away from printf synta= x? I understand about the formatting specifier issue, but I see no reason t= o use `{}` over the well-known `%` syntax. Is it just to appease C# users?<= br>

What's the point of %s vs. %d?   In the= typesafe printf example in http://www.generic-programming.org/~dgregor/cpp= /variadic-templates.html the conversion specifier is completely ignored, yo= u can say printf("%s %d", 1, "two") and it works correctly.  So if you= don't need the conversion specifier to DTRT then why use it?   A= new proposal doesn't have to use {}, it could use %1, %2 etc. or something= else. I happen to like Python's format string syntax, although obviously e= xpecting "{first} {second}".format(make_pair(1,2)) in C++ is unrealistic!

--
 
---
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/group/std-pro= posals/?hl=3Den.
 
 
------=_Part_471_7255459.1368558595448-- .