So you can write

  cout << putf("info %1%: %2%\n", 3, msg);

The syntax is as same as Boost.Format's position-only syntax:

http://www.boost.org/doc/libs/1_53_0/libs/format/doc/format.html#syntax

, which is merely a shortcut to %N$s.  The only difference is, if the
supplied arguments go beyond N, Boost.Format regards it as an error,
while `std::puf` does not.

It seems that this syntax is widely used in industry, and it makes
sense in some simple scenarios like logging.  With this change,
`std::putf` can be used as a drop-in replacement of Boost.Format
if only the simple syntax is used in the code.

https://github.com/lichray/formatxx/tree/boost-simple

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_256_9742857.1368148765587
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, May 9, 2013 11:26:21 AM UTC-7, Zhihao Yuan wrote:
>
> So you can write
>
>   cout << putf("info %1%: %2%\n", 3, msg);
>
> The syntax is as same as Boost.Format's position-only syntax:
>
> http://www.boost.org/doc/libs/1_53_0/libs/format/doc/format.html#syntax
>
> , which is merely a shortcut to %N$s.  The only difference is, if the
> supplied arguments go beyond N, Boost.Format regards it as an error,
> while `std::puf` does not.
>
> It seems that this syntax is widely used in industry, and it makes
> sense in some simple scenarios like logging.  With this change,
> `std::putf` can be used as a drop-in replacement of Boost.Format
> if only the simple syntax is used in the code.
>
> https://github.com/lichray/formatxx/tree/boost-simple
>

Speaking of N3506, how did that proposal fare at the committee meeting?

--

---
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_256_9742857.1368148765587
Content-Type: text/html; charset=ISO-8859-1

On Thursday, May 9, 2013 11:26:21 AM UTC-7, Zhihao Yuan wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So you can write
<br>
<br>&nbsp; cout &lt;&lt; putf("info %1%: %2%\n", 3, msg);
<br>
<br>The syntax is as same as Boost.Format's position-only syntax:
<br>
<br><a href="http://www.boost.org/doc/libs/1_53_0/libs/format/doc/format.html#syntax" target="_blank">http://www.boost.org/doc/libs/<wbr>1_53_0/libs/format/doc/format.<wbr>html#syntax</a>
<br>
<br>, which is merely a shortcut to %N$s. &nbsp;The only difference is, if the
<br>supplied arguments go beyond N, Boost.Format regards it as an error,
<br>while `std::puf` does not.
<br>
<br>It seems that this syntax is widely used in industry, and it makes
<br>sense in some simple scenarios like logging. &nbsp;With this change,
<br>`std::putf` can be used as a drop-in replacement of Boost.Format
<br>if only the simple syntax is used in the code.
<br>
<br><a href="https://github.com/lichray/formatxx/tree/boost-simple" target="_blank">https://github.com/lichray/<wbr>formatxx/tree/boost-simple</a>
<br></blockquote><div><br>Speaking of N3506, how did that proposal fare at the committee meeting?<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_256_9742857.1368148765587--

.

On Thu, May 9, 2013 at 9:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Speaking of N3506, how did that proposal fare at the committee meeting?

I failed to find people to champion it, so I guess it's skipped.  I'll go
to Chicago this September anyway, but I guess this can only target
a TS then.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_3207_26190129.1368465282085
Content-Type: text/plain; charset=ISO-8859-1



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"

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.


--

---
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_3207_26190129.1368465282085
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, May 10, 2013 2:19:25 AM UTC+1, Nicol Bolas wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div><br>Speaking of N3506, how d=
id that proposal fare at the committee meeting?<br></div></blockquote><div>=
<br>I wasn't in the room for the discussion but the straw polls showed no c=
onsensus for adding putf() with only printf-style formatting, strong opposi=
tion to adding non-printf-style formatting to putf, and unanimous support f=
or "a separate format string paper that is not constrained by printf"<br><b=
r>So no support for adding this, partly because with variadic templates the=
 conversion specifier after the % is redundant, the stream knows the type a=
nyway.&nbsp; Strong support for something else using a different syntax suc=
h as {} and move away from printf style.<br>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3207_26190129.1368465282085--

.

------=_Part_975_1203927.1368481170342
Content-Type: text/plain; charset=ISO-8859-1

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". But they *do*want "a separate format string paper that is not constrained by printf".
How does that make sense?

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?

--

---
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_975_1203927.1368481170342
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, May 13, 2013 10:14:42 AM UTC-7, Jonathan Wakely wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Friday, May 10, 2013 2:19:25 AM UTC+1=
, Nicol Bolas wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>Sp=
eaking of N3506, how did that proposal fare at the committee meeting?<br></=
div></blockquote><div><br>I wasn't in the room for the discussion but the s=
traw polls showed no consensus for adding putf() with only printf-style for=
matting, strong opposition to adding non-printf-style formatting to putf, a=
nd unanimous support for "a separate format string paper that is not constr=
ained by printf"<br></div></blockquote><div><br>Wait. So they <i>don't</i> =
want "non-printf-style formatting". But they <i>do</i> want "a separate for=
mat string paper that is not constrained by printf". How does that make sen=
se?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>So no su=
pport for adding this, partly because with variadic templates the conversio=
n specifier after the % is redundant, the stream knows the type anyway.&nbs=
p; Strong support for something else using a different syntax such as {} an=
d move away from printf style.</div></blockquote><div><br>Why exactly do th=
ey 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 `%` sy=
ntax. Is it just to appease C# users?<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_975_1203927.1368481170342--

.

On Mon, May 13, 2013 at 5:39 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> 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". But they do want "a
> separate format string paper that is not constrained by printf". How does
> that make sense?

The information I read is, they may or may not want a printf-style formatting,
but `putf` should not be furtherly extended (I tend to agree since it's actually
complex).  But they do interested in a modern formatting.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/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

<br><br>On Monday, May 13, 2013 10:39:30 PM UTC+1, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On Monday, May 13, 2013 10:14:42 AM =
UTC-7, Jonathan Wakely wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri=
day, May 10, 2013 2:19:25 AM UTC+1, Nicol Bolas wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div><br>Speaking of N3506, how did that proposal fa=
re at the committee meeting?<br></div></blockquote><div><br>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"<br></div></blockquote><d=
iv><br>Wait. So they <i>don't</i> want "non-printf-style formatting".</div>=
</blockquote><div><br>Some people did not want a std::putf() with printf-st=
yle formatting *and* non-printf extensions.&nbsp; i.e. if it is based on pr=
intf it should support *only* printf formatting and nothing else.<br>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> But they <i>do</i>=
 want "a separate format string paper that is not constrained by printf". H=
ow does that make sense?<br></div></blockquote><div><br>People would rather=
 see something entirely different to printf, not something based on printf.=
<br><br>I don't think those two views conflict.&nbsp; <br><br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div>So no support for adding this, partly because =
with variadic templates the conversion specifier after the % is redundant, =
the stream knows the type anyway.&nbsp; Strong support for something else u=
sing a different syntax such as {} and move away from printf style.</div></=
blockquote><div><br>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></div></blockquote><div><br>What's the point of %s vs. %d? &nbsp; 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.&nbsp; So if you=
 don't need the conversion specifier to DTRT then why use it?&nbsp;&nbsp; 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!<b=
r><br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_471_7255459.1368558595448--

.

On Tue, May 14, 2013 at 12:09 PM, Jonathan Wakely <cxx@kayari.org> wrote:
>
>
> 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.

The reasoning behind this was that
1) The reason to use printf-style format strings in putf() is to let
people re-use their existing format strings.
2) If we add a new semantic character to the format strings, some
existing format strings would change behavior, forcing users to audit
all of their strings.
3) So if putf() uses printd-style format strings, it shouldn't extend
them at all.

I don't particularly agree with this reasoning, but it convinced 6/7
of the people there.

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

--

---
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_1961_31732967.1368569428596
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, May 14, 2013 12:09:55 PM UTC-7, Jonathan Wakely wrote:
>
> 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:
>>>
>>> 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.htmlthe conversion specifier is completely ignored, you can say printf("%s %d",
> 1, "two") and it works correctly.
>

I assume you're using the word "correctly" very loosely, since "%08x"
doesn't work at all. N3506 would have allowed that to work.

So *that* is the point of those specifiers: they allow you to provide
formatting information.

--

---
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_1961_31732967.1368569428596
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 14, 2013 12:09:55 PM UTC-7, Jonathan Wakely wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On Monday, May 13, 2013 10:39:30 PM UTC=
+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, Ma=
y 13, 2013 10:14:42 AM UTC-7, Jonathan Wakely wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div>So no support for adding this, partly because with va=
riadic templates the conversion specifier after the % is redundant, the str=
eam knows the type anyway.&nbsp; Strong support for something else using a =
different syntax such as {} and move away from printf style.</div></blockqu=
ote><div><br>Why exactly do they want to move away from printf syntax? I un=
derstand about the formatting specifier issue, but I see no reason to use `=
{}` over the well-known `%` syntax. Is it just to appease C# users?<br></di=
v></blockquote><div><br>What's the point of %s vs. %d? &nbsp; In the typesa=
fe printf example in <a href=3D"http://www.generic-programming.org/~dgregor=
/cpp/variadic-templates.html" target=3D"_blank">http://www.generic-<wbr>pro=
gramming.org/~dgregor/cpp/<wbr>variadic-templates.html</a> the conversion s=
pecifier is completely ignored, you can say printf("%s %d", 1, "two") and i=
t works correctly.</div></blockquote><div><br>I assume you're using the wor=
d "correctly" very loosely, since "%08x" doesn't work at all. N3506 would h=
ave allowed that to work.<br><br>So <i>that</i> is the point of those speci=
fiers: they allow you to provide formatting information.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1961_31732967.1368569428596--

.

------=_Part_2003_33207880.1368569707333
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, May 14, 2013 12:40:48 PM UTC-7, Jeffrey Yasskin wrote:
>
> On Tue, May 14, 2013 at 12:09 PM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> >
> >
> > 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.
>
> The reasoning behind this was that
> 1) The reason to use printf-style format strings in putf() is to let
> people re-use their existing format strings.
> 2) If we add a new semantic character to the format strings, some
> existing format strings would change behavior, forcing users to audit
> all of their strings.
> 3) So if putf() uses printd-style format strings, it shouldn't extend
> them at all.
>
> I don't particularly agree with this reasoning, but it convinced 6/7
> of the people there.
>

The place where the logic breaks down for me is with #1.

The reason to use printf-style syntax is because it is *familiar*, not for
drop-in backwards compatibility (though that's also nice). There's no
reason to reinvent the wheel here. People know and understand how printf
syntax works, so we should leverage that where possible.

What we don't want is for C++ users to have to learn two completely
different formatting syntaxes. They're going to have to learn printf,
because there's lots of printf code that isn't going anywhere. So we may as
well extend that with useful functionality like positional arguments.

--

---
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_2003_33207880.1368569707333
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 14, 2013 12:40:48 PM UTC-7, Jeffrey Yasskin wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On Tue, May 14, 2013 at 12:09 PM, Jonat=
han Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"kJn9jPFMeJ4J">c...@kayari.org</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Monday, May 13, 2013 10:39:30 PM UTC+1, Nicol Bolas wrote:
<br>&gt;&gt;
<br>&gt;&gt; On Monday, May 13, 2013 10:14:42 AM UTC-7, Jonathan Wakely wro=
te:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; On Friday, May 10, 2013 2:19:25 AM UTC+1, Nicol Bolas wrot=
e:
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt; Speaking of N3506, how did that proposal fare at the c=
ommittee meeting?
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; I wasn't in the room for the discussion but the straw poll=
s showed no
<br>&gt;&gt;&gt; consensus for adding putf() with only printf-style formatt=
ing, strong
<br>&gt;&gt;&gt; opposition to adding non-printf-style formatting to putf, =
and unanimous
<br>&gt;&gt;&gt; support for "a separate format string paper that is not co=
nstrained by
<br>&gt;&gt;&gt; printf"
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Wait. So they don't want "non-printf-style formatting".
<br>&gt;
<br>&gt;
<br>&gt; Some people did not want a std::putf() with printf-style formattin=
g *and*
<br>&gt; non-printf extensions. &nbsp;i.e. if it is based on printf it shou=
ld support
<br>&gt; *only* printf formatting and nothing else.
<br>
<br>The reasoning behind this was that
<br>1) The reason to use printf-style format strings in putf() is to let
<br>people re-use their existing format strings.
<br>2) If we add a new semantic character to the format strings, some
<br>existing format strings would change behavior, forcing users to audit
<br>all of their strings.
<br>3) So if putf() uses printd-style format strings, it shouldn't extend
<br>them at all.
<br>
<br>I don't particularly agree with this reasoning, but it convinced 6/7
<br>of the people there.<br></blockquote><div><br>The place where the logic=
 breaks down for me is with #1.<br><br>The reason to use printf-style synta=
x is because it is <i>familiar</i>, not for drop-in backwards compatibility=
 (though that's also nice). There's no reason to reinvent the wheel here. P=
eople know and understand how printf syntax works, so we should leverage th=
at where possible.<br><br>What we don't want is for C++ users to have to le=
arn two completely different formatting syntaxes. They're going to have to =
learn printf, because there's lots of printf code that isn't going anywhere=
.. So we may as well extend that with useful functionality like positional a=
rguments.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2003_33207880.1368569707333--

.

------=_Part_4132_24413295.1368586892265
Content-Type: text/plain; charset=ISO-8859-1


>
>  People know and understand how printf syntax works, so we should leverage
> that where possible.


Being consistent is only a good thing if you're being consistent with
something that is not horrifically broken. As Jeffrey said, if you're going
to be compatible with printf, then you need to be completely compatible.
Else, you should do something that actually works and makes sense. There is
much experience in this from formatting in other languages like Python and
C#.

Ultimately, when you have a broken component, it's fine to introduce a
redesign which is better, and it's fine to introduce a new component that
is somewhat better but has compatibility. printf-like-but-not-quite does
not address anyone's use case.

--

---
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_4132_24413295.1368586892265
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">&nbsp;People know and understand how printf sy=
ntax works, so we should leverage that where possible.</blockquote><div><br=
></div><div>Being consistent is only a good thing if you're being consisten=
t with something that is not horrifically broken. As Jeffrey said, if you'r=
e going to be compatible with printf, then you need to be completely compat=
ible. Else, you should do something that actually works and makes sense. Th=
ere is much experience in this from formatting in other languages like Pyth=
on and C#.</div><div><br></div><div>Ultimately, when you have a broken comp=
onent, it's fine to introduce a redesign which is better, and it's fine to =
introduce a new component that is somewhat better but has compatibility. pr=
intf-like-but-not-quite does not address anyone's use case.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4132_24413295.1368586892265--

.

On Tue, May 14, 2013 at 11:01 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> Being consistent is only a good thing if you're being consistent with
> something that is not horrifically broken. As Jeffrey said, if you're going
> to be compatible with printf, then you need to be completely compatible.
> Else, you should do something that actually works and makes sense. There is
> much experience in this from formatting in other languages like Python and
> C#.

IMHO, the **idea** behind printf actually works and makes sense.  And
'completely compatible' only makes sense when a new thing is compatible
to the **working** parts of and old thing.  And that's why I kept the full
compatibility with C-printf and let the **idea** continue to work for the new
stuff in C++ like classes.

> Ultimately, when you have a broken component, it's fine to introduce a
> redesign which is better, and it's fine to introduce a new component that is
> somewhat better but has compatibility. printf-like-but-not-quite does not
> address anyone's use case.

If you look at the proposal, 1st, it's not broken; 2nd, it's absolutely not
"printf-like-but-not-quite".  I tend to describe it as "printf-as-it-should-be",
since C-printf does not make the **idea** of printf work (sometimes, and
sometimes in C++).

It's OK to have a new design, but I don't see a drawback to have one
design which worked and is going to work.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_2140_23858953.1368590618758
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, May 14, 2013 8:01:32 PM UTC-7, DeadMG wrote:
>
>  People know and understand how printf syntax works, so we should leverage
>> that where possible.
>
>
> Being consistent is only a good thing if you're being consistent with
> something that is not horrifically broken. As Jeffrey said, if you're going
> to be compatible with printf, then you need to be completely compatible.
>

First, as I recall, Jeffrey himself didn't agree; he's just reporting the
reasoning.

Second, saying that printf is "horrifically broken" *doesn't make it true*.
If you're going to claim that printf is "horrifically broken", you should
back that up with some form of argument.

--

---
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_2140_23858953.1368590618758
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 14, 2013 8:01:32 PM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex">&nbsp;People know and understa=
nd how printf syntax works, so we should leverage that where possible.</blo=
ckquote><div><br></div><div>Being consistent is only a good thing if you're=
 being consistent with something that is not horrifically broken. As Jeffre=
y said, if you're going to be compatible with printf, then you need to be c=
ompletely compatible.</div></blockquote><div><br>First, as I recall, Jeffre=
y himself didn't agree; he's just reporting the reasoning.<br><br>Second, s=
aying that printf is "horrifically broken" <i>doesn't make it true</i>. If =
you're going to claim that printf is "horrifically broken", you should back=
 that up with some form of argument.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2140_23858953.1368590618758--

.

------=_Part_441_12470187.1368598632364
Content-Type: text/plain; charset=ISO-8859-1

I didn't say he agreed, only that he said it. I was also in the room for
this proposal and agreed with the majority decision.

Second, saying that printf is "horrifically broken" doesn't make it true.
> If you're going to claim that printf is "horrifically broken", you should
> back that up with some form of argument


Well, we'll start with, say, the redundant type information in the format
specifiers. Then we'll move on to the complete lack of extensibility for
specifiers. No positional arguments. How about locales? printf can't take a
std::locale. I think I'll take a breath there.

 And that's why I kept the full compatibility with C-printf and let the
> **idea** continue to work for the new stuff in C++ like classes.


It is not full compatibility if there exist printf format strings that do
not function with std::putf. We discussed something about how you would now
have to escape curly braces which previously did not need escaping. As long
as these specifiers exist, you do not have compatibility.

As I said before, I can see an argument for "It's compatible and somewhat
better", and I can see that this might justify the inclusion of a Standard
component. But if you want to make that argument *you have to actually have
compatibility.* And I can also see the argument that we could use something
"It's like printf, but doesn't suck.". But if you want to make that
argument,* *you need something which is actually considerably better and
drops all the undesirable legacy crap. Normally, I would qualify that by
saying that it's fine to support both in one component if possible, but in
this case that is definitively impossible.

Jeffrey's string_view paper also suffered from exactly this problem- it
tried to be too many things to too many people and didn't actually achieve
either goal.

--

---
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_441_12470187.1368598632364
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I didn't say he agreed, only that he said it. I was also in the room for th=
is proposal and agreed with the majority decision.<br><br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px=
; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-=
left: 1ex;">Second, saying that printf is "horrifically broken" doesn't mak=
e it true. If you're going to claim that printf is "horrifically broken", y=
ou should back that up with some form of argument</blockquote><div><br></di=
v><div>Well, we'll start with, say, the redundant type information in the f=
ormat specifiers. Then we'll move on to the complete lack of extensibility =
for specifiers. No positional arguments. How about locales? printf can't ta=
ke a std::locale. I think I'll take a breath there.</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: s=
olid; padding-left: 1ex;">&nbsp;And that's why I kept the full compatibilit=
y with C-printf and let the **idea** continue to work for the new stuff in =
C++ like classes.&nbsp;</blockquote><div><br></div><div>It is not full comp=
atibility if there exist printf format strings that do not function with st=
d::putf. We discussed something about how you would now have to escape curl=
y braces which previously did not need escaping. As long as these specifier=
s exist, you do not have compatibility.</div><div><br></div><div>As I said =
before, I can see an argument for "It's compatible and somewhat better", an=
d I can see that this might justify the inclusion of a Standard component. =
But if you want to make that argument <i>you have to actually have compatib=
ility.</i>&nbsp;And I can also see the argument that we could use something=
 "It's like printf, but doesn't suck.". But if you want to make that argume=
nt,<i>&nbsp;</i>you need something which is actually considerably better an=
d drops all the undesirable legacy crap. Normally, I would qualify that by =
saying that it's fine to support both in one component if possible, but in =
this case that is definitively impossible.</div><div><br></div><div>Jeffrey=
's string_view paper also suffered from exactly this problem- it tried to b=
e too many things to too many people and didn't actually achieve either goa=
l.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_441_12470187.1368598632364--

.

------=_Part_392_743218.1368604128692
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:
>
> I didn't say he agreed, only that he said it. I was also in the room for
> this proposal and agreed with the majority decision.
>
> Second, saying that printf is "horrifically broken" doesn't make it true.
>> If you're going to claim that printf is "horrifically broken", you should
>> back that up with some form of argument
>
>
> Well, we'll start with, say, the redundant type information in the format
> specifiers. Then we'll move on to the complete lack of extensibility for
> specifiers. No positional arguments. How about locales? printf can't take a
> std::locale. I think I'll take a breath there.
>

Having features that are redundant doesn't make something "broken"; it
makes it "redundant." Lacking features *does not* make something "broken".
It makes it *deficient*. Broken means "non-functional;" it cannot be used.
Lacking features means that it can't be used for those specific things uses
that need those features.

printf can be, and is still being, used. Ergo not *broken*.

 And that's why I kept the full compatibility with C-printf and let the
>> **idea** continue to work for the new stuff in C++ like classes.
>
>
> It is not full compatibility if there exist printf format strings that do
> not function with std::putf. We discussed something about how you would now
> have to escape curly braces which previously did not need escaping. As long
> as these specifiers exist, you do not have compatibility.
>

But nobody has suggested that there would be any such issues. You don't
have to escape curly braces because curly braces are not used. I don't even
know where you're getting the idea that curly braces are part of any such
proposal.

Further, the N3506 proposal specifically states that you can not
mix-and-match positional arguments with traditional printf arguments. So a
string that is a legitimate `printf` format will produce the same results
with `putf`.

Personally, I think it is unnecessary to separate the two, since "%n$" and
"%n%" are both invalid for printf. Since such syntax would break with
`printf`, there's no harm in allowing it to have a meaning with `putf`.

In short, N3506 is entirely backwards compatible with printf.


> As I said before, I can see an argument for "It's compatible and somewhat
> better", and I can see that this might justify the inclusion of a Standard
> component. But if you want to make that argument *you have to actually
> have compatibility.* And I can also see the argument that we could use
> something "It's like printf, but doesn't suck.". But if you want to make
> that argument,* *you need something which is actually considerably better
> and drops all the undesirable legacy crap.
>

There's the problem: the assumption that "considerably better" *requires*that you "drop all the undesirable legacy crap". I see absolutely no reason
why that's necessary. There's no reason why you can't have positional
arguments or extensible formatting specification (though I have no idea
what that would even look like) while also having backwards compatibility
with printf.

The only reason you can't is if you assume that you have to abandon `%` as
the inducer for a format.

Normally, I would qualify that by saying that it's fine to support both in
> one component if possible, but in this case that is definitively impossible.
>

Except that it's not impossible, as shown by N3506.

--

---
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_392_743218.1368604128692
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I didn't say he agreed, only that he said it. I=
 was also in the room for this proposal and agreed with the majority decisi=
on.<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex">Second, saying that printf is "horrifically bro=
ken" doesn't make it true. If you're going to claim that printf is "horrifi=
cally broken", you should back that up with some form of argument</blockquo=
te><div><br></div><div>Well, we'll start with, say, the redundant type info=
rmation in the format specifiers. Then we'll move on to the complete lack o=
f extensibility for specifiers. No positional arguments. How about locales?=
 printf can't take a std::locale. I think I'll take a breath there.</div></=
blockquote><div><br>Having features that are redundant doesn't make somethi=
ng "broken"; it makes it "redundant." Lacking features <i>does not</i> make=
 something "broken". It makes it <i>deficient</i>. Broken means "non-functi=
onal;" it cannot be used. Lacking features means that it can't be used for =
those specific things uses that need those features.<br><br>printf can be, =
and is still being, used. Ergo not <i>broken</i>.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">&nbsp;And that's why I ke=
pt the full compatibility with C-printf and let the **idea** continue to wo=
rk for the new stuff in C++ like classes.&nbsp;</blockquote><div><br></div>=
<div>It is not full compatibility if there exist printf format strings that=
 do not function with std::putf. We discussed something about how you would=
 now have to escape curly braces which previously did not need escaping. As=
 long as these specifiers exist, you do not have compatibility.</div></bloc=
kquote><div><br>But nobody has suggested that there would be any such issue=
s. You don't have to escape curly braces because curly braces are not used.=
 I don't even know where you're getting the idea that curly braces are part=
 of any such proposal.<br><br>Further, the N3506 proposal specifically stat=
es that you can not mix-and-match positional arguments with traditional pri=
ntf arguments. So a string that is a legitimate `printf` format will produc=
e the same results with `putf`.<br><br>Personally, I think it is unnecessar=
y to separate the two, since "%n$" and "%n%" are both invalid for printf. S=
ince such syntax would break with `printf`, there's no harm in allowing it =
to have a meaning with `putf`.<br><br>In short, N3506 is entirely backwards=
 compatible with printf.<br>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div></div><div>As I said before, I can see an argument for "It's=
 compatible and somewhat better", and I can see that this might justify the=
 inclusion of a Standard component. But if you want to make that argument <=
i>you have to actually have compatibility.</i>&nbsp;And I can also see the =
argument that we could use something "It's like printf, but doesn't suck.".=
 But if you want to make that argument,<i>&nbsp;</i>you need something whic=
h is actually considerably better and drops all the undesirable legacy crap=
..</div></blockquote><div><br>There's the problem: the assumption that "cons=
iderably better" <i>requires</i> that you "drop all the undesirable legacy =
crap". I see absolutely no reason why that's necessary. There's no reason w=
hy you can't have positional arguments or extensible formatting specificati=
on (though I have no idea what that would even look like) while also having=
 backwards compatibility with printf.<br><br>The only reason you can't is i=
f you assume that you have to abandon `%` as the inducer for a format.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Normally, I woul=
d qualify that by saying that it's fine to support both in one component if=
 possible, but in this case that is definitively impossible.</div></blockqu=
ote><div><br>Except that it's not impossible, as shown by N3506.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_392_743218.1368604128692--

.

------=_Part_4563_4570527.1368605212874
Content-Type: text/plain; charset=ISO-8859-1


>
> But nobody has suggested that there would be any such issues


The information the LEWG received in Bristol was quite the opposite. It was
clearly stated by the presenter of the paper that there was a collision and
that not all printf format strings would function. Perhaps he didn't
understand the paper, or perhaps you don't. In either case, if you wish to
understand the LEWG response to this paper, you have to come at it with the
information we were given- specifically, that there was a clash between the
new functionality proposed and the existing specifiers, and std::putf did
not offer backwards compatibility with printf for this reason. If you
disagree with the suggestion that there was a clash breaking some printf
format strings, ask the guy who made that assessment.

 Lacking features *does not* make something "broken". It makes it *deficient
> *.


This distinction is irrelevant. Either it meets the requirements or it does
not.

 Broken means "non-functional;" it cannot be used.


People use broken things all the time- particularly when there is no
non-broken alternative provided, for which printf is a fine example.

--

---
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_4563_4570527.1368605212874
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">But nobody has suggested that there would be a=
ny such issues</blockquote><div><br></div>The information the LEWG received=
 in Bristol was quite the opposite. It was clearly stated by the presenter =
of the paper that there was a collision and that not all printf format stri=
ngs would function. Perhaps he didn't understand the paper, or perhaps you =
don't. In either case, if you wish to understand the LEWG response to this =
paper, you have to come at it with the information we were given- specifica=
lly, that there was a clash between the new functionality proposed and the =
existing specifiers, and std::putf did not offer backwards compatibility wi=
th printf for this reason. If you disagree with the suggestion that there w=
as a clash breaking some printf format strings, ask the guy who made that a=
ssessment.<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204=
, 204); border-left-style: solid; padding-left: 1ex;">&nbsp;Lacking feature=
s&nbsp;<i>does not</i>&nbsp;make something "broken". It makes it&nbsp;<i>de=
ficient</i>.</blockquote><div><br></div><div>This distinction is irrelevant=
.. Either it meets the requirements or it does not.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: so=
lid; padding-left: 1ex;">&nbsp;Broken means "non-functional;" it cannot be =
used.</blockquote><div><br></div><div>People use broken things all the time=
- particularly when there is no non-broken alternative provided, for which =
printf is a fine example.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4563_4570527.1368605212874--

.

On Wed, May 15, 2013 at 12:48 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:
>>
>> I didn't say he agreed, only that he said it. I was also in the room for
>> this proposal and agreed with the majority decision.
>>
>>> Second, saying that printf is "horrifically broken" doesn't make it true.
>>> If you're going to claim that printf is "horrifically broken", you should
>>> back that up with some form of argument
>>
>>
>> Well, we'll start with, say, the redundant type information in the format
>> specifiers. Then we'll move on to the complete lack of extensibility for
>> specifiers. No positional arguments. How about locales? printf can't take a
>> std::locale. I think I'll take a breath there.
>
>
> Having features that are redundant doesn't make something "broken"; it makes
> it "redundant." Lacking features does not make something "broken". It makes
> it deficient. Broken means "non-functional;" it cannot be used. Lacking
> features means that it can't be used for those specific things uses that
> need those features.
>
> printf can be, and is still being, used. Ergo not broken.
>
>>>  And that's why I kept the full compatibility with C-printf and let the
>>> **idea** continue to work for the new stuff in C++ like classes.
>>
>>
>> It is not full compatibility if there exist printf format strings that do
>> not function with std::putf. We discussed something about how you would now
>> have to escape curly braces which previously did not need escaping. As long
>> as these specifiers exist, you do not have compatibility.
>
>
> But nobody has suggested that there would be any such issues. You don't have
> to escape curly braces because curly braces are not used. I don't even know
> where you're getting the idea that curly braces are part of any such
> proposal.
>
> Further, the N3506 proposal specifically states that you can not
> mix-and-match positional arguments with traditional printf arguments. So a
> string that is a legitimate `printf` format will produce the same results
> with `putf`.
>
> Personally, I think it is unnecessary to separate the two, since "%n$" and
> "%n%" are both invalid for printf. Since such syntax would break with
> `printf`, there's no harm in allowing it to have a meaning with `putf`.

FWIW, %n$...c is valid for printf, and has the same meaning as in this
proposal: http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.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/?hl=en.



.

------=_Part_5165_5386543.1368637157531
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, May 15, 2013 9:27:38 AM UTC-7, Jeffrey Yasskin wrote:
>
> On Wed, May 15, 2013 at 12:48 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:
> >>
> >> I didn't say he agreed, only that he said it. I was also in the room
> for
> >> this proposal and agreed with the majority decision.
> >>
> >>> Second, saying that printf is "horrifically broken" doesn't make it
> true.
> >>> If you're going to claim that printf is "horrifically broken", you
> should
> >>> back that up with some form of argument
> >>
> >>
> >> Well, we'll start with, say, the redundant type information in the
> format
> >> specifiers. Then we'll move on to the complete lack of extensibility
> for
> >> specifiers. No positional arguments. How about locales? printf can't
> take a
> >> std::locale. I think I'll take a breath there.
> >
> >
> > Having features that are redundant doesn't make something "broken"; it
> makes
> > it "redundant." Lacking features does not make something "broken". It
> makes
> > it deficient. Broken means "non-functional;" it cannot be used. Lacking
> > features means that it can't be used for those specific things uses that
> > need those features.
> >
> > printf can be, and is still being, used. Ergo not broken.
> >
> >>>  And that's why I kept the full compatibility with C-printf and let
> the
> >>> **idea** continue to work for the new stuff in C++ like classes.
> >>
> >>
> >> It is not full compatibility if there exist printf format strings that
> do
> >> not function with std::putf. We discussed something about how you would
> now
> >> have to escape curly braces which previously did not need escaping. As
> long
> >> as these specifiers exist, you do not have compatibility.
> >
> >
> > But nobody has suggested that there would be any such issues. You don't
> have
> > to escape curly braces because curly braces are not used. I don't even
> know
> > where you're getting the idea that curly braces are part of any such
> > proposal.
> >
> > Further, the N3506 proposal specifically states that you can not
> > mix-and-match positional arguments with traditional printf arguments. So
> a
> > string that is a legitimate `printf` format will produce the same
> results
> > with `putf`.
> >
> > Personally, I think it is unnecessary to separate the two, since "%n$"
> and
> > "%n%" are both invalid for printf. Since such syntax would break with
> > `printf`, there's no harm in allowing it to have a meaning with `putf`.
>
> FWIW, %n$...c is valid for printf, and has the same meaning as in this
> proposal:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>

Which version of C is this true for?

--

---
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_5165_5386543.1368637157531
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, May 15, 2013 9:27:38 AM UTC-7, Jeffrey Yasskin wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Wed, May 15, 2013 at 12:48 =
AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"4YjUV76W3w4J">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:
<br>&gt;&gt;
<br>&gt;&gt; I didn't say he agreed, only that he said it. I was also in th=
e room for
<br>&gt;&gt; this proposal and agreed with the majority decision.
<br>&gt;&gt;
<br>&gt;&gt;&gt; Second, saying that printf is "horrifically broken" doesn'=
t make it true.
<br>&gt;&gt;&gt; If you're going to claim that printf is "horrifically brok=
en", you should
<br>&gt;&gt;&gt; back that up with some form of argument
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Well, we'll start with, say, the redundant type information in=
 the format
<br>&gt;&gt; specifiers. Then we'll move on to the complete lack of extensi=
bility for
<br>&gt;&gt; specifiers. No positional arguments. How about locales? printf=
 can't take a
<br>&gt;&gt; std::locale. I think I'll take a breath there.
<br>&gt;
<br>&gt;
<br>&gt; Having features that are redundant doesn't make something "broken"=
; it makes
<br>&gt; it "redundant." Lacking features does not make something "broken".=
 It makes
<br>&gt; it deficient. Broken means "non-functional;" it cannot be used. La=
cking
<br>&gt; features means that it can't be used for those specific things use=
s that
<br>&gt; need those features.
<br>&gt;
<br>&gt; printf can be, and is still being, used. Ergo not broken.
<br>&gt;
<br>&gt;&gt;&gt; &nbsp;And that's why I kept the full compatibility with C-=
printf and let the
<br>&gt;&gt;&gt; **idea** continue to work for the new stuff in C++ like cl=
asses.
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; It is not full compatibility if there exist printf format stri=
ngs that do
<br>&gt;&gt; not function with std::putf. We discussed something about how =
you would now
<br>&gt;&gt; have to escape curly braces which previously did not need esca=
ping. As long
<br>&gt;&gt; as these specifiers exist, you do not have compatibility.
<br>&gt;
<br>&gt;
<br>&gt; But nobody has suggested that there would be any such issues. You =
don't have
<br>&gt; to escape curly braces because curly braces are not used. I don't =
even know
<br>&gt; where you're getting the idea that curly braces are part of any su=
ch
<br>&gt; proposal.
<br>&gt;
<br>&gt; Further, the N3506 proposal specifically states that you can not
<br>&gt; mix-and-match positional arguments with traditional printf argumen=
ts. So a
<br>&gt; string that is a legitimate `printf` format will produce the same =
results
<br>&gt; with `putf`.
<br>&gt;
<br>&gt; Personally, I think it is unnecessary to separate the two, since "=
%n$" and
<br>&gt; "%n%" are both invalid for printf. Since such syntax would break w=
ith
<br>&gt; `printf`, there's no harm in allowing it to have a meaning with `p=
utf`.
<br>
<br>FWIW, %n$...c is valid for printf, and has the same meaning as in this
<br>proposal: <a href=3D"http://pubs.opengroup.org/onlinepubs/9699919799/fu=
nctions/printf.html" target=3D"_blank">http://pubs.opengroup.org/<wbr>onlin=
epubs/9699919799/<wbr>functions/printf.html</a>
<br></blockquote><div><br>Which version of C is this true for? <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_5165_5386543.1368637157531--

.

On Wed, May 15, 2013 at 9:59 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Wednesday, May 15, 2013 9:27:38 AM UTC-7, Jeffrey Yasskin wrote:
>>
>> On Wed, May 15, 2013 at 12:48 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:
>> >>
>> >> I didn't say he agreed, only that he said it. I was also in the room
>> >> for
>> >> this proposal and agreed with the majority decision.
>> >>
>> >>> Second, saying that printf is "horrifically broken" doesn't make it
>> >>> true.
>> >>> If you're going to claim that printf is "horrifically broken", you
>> >>> should
>> >>> back that up with some form of argument
>> >>
>> >>
>> >> Well, we'll start with, say, the redundant type information in the
>> >> format
>> >> specifiers. Then we'll move on to the complete lack of extensibility
>> >> for
>> >> specifiers. No positional arguments. How about locales? printf can't
>> >> take a
>> >> std::locale. I think I'll take a breath there.
>> >
>> >
>> > Having features that are redundant doesn't make something "broken"; it
>> > makes
>> > it "redundant." Lacking features does not make something "broken". It
>> > makes
>> > it deficient. Broken means "non-functional;" it cannot be used. Lacking
>> > features means that it can't be used for those specific things uses that
>> > need those features.
>> >
>> > printf can be, and is still being, used. Ergo not broken.
>> >
>> >>>  And that's why I kept the full compatibility with C-printf and let
>> >>> the
>> >>> **idea** continue to work for the new stuff in C++ like classes.
>> >>
>> >>
>> >> It is not full compatibility if there exist printf format strings that
>> >> do
>> >> not function with std::putf. We discussed something about how you would
>> >> now
>> >> have to escape curly braces which previously did not need escaping. As
>> >> long
>> >> as these specifiers exist, you do not have compatibility.
>> >
>> >
>> > But nobody has suggested that there would be any such issues. You don't
>> > have
>> > to escape curly braces because curly braces are not used. I don't even
>> > know
>> > where you're getting the idea that curly braces are part of any such
>> > proposal.
>> >
>> > Further, the N3506 proposal specifically states that you can not
>> > mix-and-match positional arguments with traditional printf arguments. So
>> > a
>> > string that is a legitimate `printf` format will produce the same
>> > results
>> > with `putf`.
>> >
>> > Personally, I think it is unnecessary to separate the two, since "%n$"
>> > and
>> > "%n%" are both invalid for printf. Since such syntax would break with
>> > `printf`, there's no harm in allowing it to have a meaning with `putf`.
>>
>> FWIW, %n$...c is valid for printf, and has the same meaning as in this
>> proposal:
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>
>
> Which version of C is this true for?

Ah, it's just POSIX, meaning everyone except MSVC supports it.
'course, MS made the mistake of specifying that "If a percent sign is
followed by a character that has no meaning as a format field, the
character is copied to the output unchanged."
(http://msdn.microsoft.com/en-us/library/56e442dc.aspx) instead of
leaving it undefined, so if we're worrying about them, we couldn't use
the %N% syntax either.

--

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



.

On Wed, May 15, 2013 at 2:01 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>> FWIW, %n$...c is valid for printf, and has the same meaning as in this
>>> proposal:
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>>
>>
>> Which version of C is this true for?
>
> Ah, it's just POSIX, meaning everyone except MSVC supports it.
> 'course, MS made the mistake of specifying that "If a percent sign is
> followed by a character that has no meaning as a format field, the
> character is copied to the output unchanged."
> (http://msdn.microsoft.com/en-us/library/56e442dc.aspx) instead of
> leaving it undefined, so if we're worrying about them, we couldn't use
> the %N% syntax either.

And that's why MS has `printf_p`.  It's MS's implementation mistake
to keep invalid characters, which has nothing to do with C-printf.
For C-printf, it's just safe to extend its unused characters.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_5585_2507447.1368673715860
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, May 15, 2013 11:01:07 AM UTC-7, Jeffrey Yasskin wrote:
>
> On Wed, May 15, 2013 at 9:59 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> >
> >
> > On Wednesday, May 15, 2013 9:27:38 AM UTC-7, Jeffrey Yasskin wrote:
> >>
> >> On Wed, May 15, 2013 at 12:48 AM, Nicol Bolas <jmck...@gmail.com>
> wrote:
> >> > On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:
> >> >>
> >> >> I didn't say he agreed, only that he said it. I was also in the room
> >> >> for
> >> >> this proposal and agreed with the majority decision.
> >> >>
> >> >>> Second, saying that printf is "horrifically broken" doesn't make it
> >> >>> true.
> >> >>> If you're going to claim that printf is "horrifically broken", you
> >> >>> should
> >> >>> back that up with some form of argument
> >> >>
> >> >>
> >> >> Well, we'll start with, say, the redundant type information in the
> >> >> format
> >> >> specifiers. Then we'll move on to the complete lack of extensibility
> >> >> for
> >> >> specifiers. No positional arguments. How about locales? printf can't
> >> >> take a
> >> >> std::locale. I think I'll take a breath there.
> >> >
> >> >
> >> > Having features that are redundant doesn't make something "broken";
> it
> >> > makes
> >> > it "redundant." Lacking features does not make something "broken". It
> >> > makes
> >> > it deficient. Broken means "non-functional;" it cannot be used.
> Lacking
> >> > features means that it can't be used for those specific things uses
> that
> >> > need those features.
> >> >
> >> > printf can be, and is still being, used. Ergo not broken.
> >> >
> >> >>>  And that's why I kept the full compatibility with C-printf and let
> >> >>> the
> >> >>> **idea** continue to work for the new stuff in C++ like classes.
> >> >>
> >> >>
> >> >> It is not full compatibility if there exist printf format strings
> that
> >> >> do
> >> >> not function with std::putf. We discussed something about how you
> would
> >> >> now
> >> >> have to escape curly braces which previously did not need escaping.
> As
> >> >> long
> >> >> as these specifiers exist, you do not have compatibility.
> >> >
> >> >
> >> > But nobody has suggested that there would be any such issues. You
> don't
> >> > have
> >> > to escape curly braces because curly braces are not used. I don't
> even
> >> > know
> >> > where you're getting the idea that curly braces are part of any such
> >> > proposal.
> >> >
> >> > Further, the N3506 proposal specifically states that you can not
> >> > mix-and-match positional arguments with traditional printf arguments.
> So
> >> > a
> >> > string that is a legitimate `printf` format will produce the same
> >> > results
> >> > with `putf`.
> >> >
> >> > Personally, I think it is unnecessary to separate the two, since
> "%n$"
> >> > and
> >> > "%n%" are both invalid for printf. Since such syntax would break with
> >> > `printf`, there's no harm in allowing it to have a meaning with
> `putf`.
> >>
> >> FWIW, %n$...c is valid for printf, and has the same meaning as in this
> >> proposal:
> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
> >
> >
> > Which version of C is this true for?
>
> Ah, it's just POSIX, meaning everyone except MSVC supports it.
> 'course, MS made the mistake of specifying that "If a percent sign is
> followed by a character that has no meaning as a format field, the
> character is copied to the output unchanged."
> (http://msdn.microsoft.com/en-us/library/56e442dc.aspx) instead of
> leaving it undefined, so if we're worrying about them, we couldn't use
> the %N% syntax either.
>

Right, but the *standard* doesn't have to concern itself with what others
defined from undefined behavior. That is, if you provided a
standard-conforming printf format to putf, it would work as expected. If
you don't, then you get undefined behavior from putf.

--

---
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_5585_2507447.1368673715860
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, May 15, 2013 11:01:07 AM UTC-7, Jeffrey Yasskin wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On Wed, May 15, 2013 at 9:59 =
AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"EUM_F1nV2W4J">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Wednesday, May 15, 2013 9:27:38 AM UTC-7, Jeffrey Yasskin wrote=
:
<br>&gt;&gt;
<br>&gt;&gt; On Wed, May 15, 2013 at 12:48 AM, Nicol Bolas &lt;<a>jmck...@g=
mail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; On Tuesday, May 14, 2013 11:17:12 PM UTC-7, DeadMG wrote:
<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt; I didn't say he agreed, only that he said it. I was a=
lso in the room
<br>&gt;&gt; &gt;&gt; for
<br>&gt;&gt; &gt;&gt; this proposal and agreed with the majority decision.
<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt;&gt; Second, saying that printf is "horrifically broke=
n" doesn't make it
<br>&gt;&gt; &gt;&gt;&gt; true.
<br>&gt;&gt; &gt;&gt;&gt; If you're going to claim that printf is "horrific=
ally broken", you
<br>&gt;&gt; &gt;&gt;&gt; should
<br>&gt;&gt; &gt;&gt;&gt; back that up with some form of argument
<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt; Well, we'll start with, say, the redundant type infor=
mation in the
<br>&gt;&gt; &gt;&gt; format
<br>&gt;&gt; &gt;&gt; specifiers. Then we'll move on to the complete lack o=
f extensibility
<br>&gt;&gt; &gt;&gt; for
<br>&gt;&gt; &gt;&gt; specifiers. No positional arguments. How about locale=
s? printf can't
<br>&gt;&gt; &gt;&gt; take a
<br>&gt;&gt; &gt;&gt; std::locale. I think I'll take a breath there.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Having features that are redundant doesn't make something=
 "broken"; it
<br>&gt;&gt; &gt; makes
<br>&gt;&gt; &gt; it "redundant." Lacking features does not make something =
"broken". It
<br>&gt;&gt; &gt; makes
<br>&gt;&gt; &gt; it deficient. Broken means "non-functional;" it cannot be=
 used. Lacking
<br>&gt;&gt; &gt; features means that it can't be used for those specific t=
hings uses that
<br>&gt;&gt; &gt; need those features.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; printf can be, and is still being, used. Ergo not broken.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt;&gt;&gt; &nbsp;And that's why I kept the full compatibilit=
y with C-printf and let
<br>&gt;&gt; &gt;&gt;&gt; the
<br>&gt;&gt; &gt;&gt;&gt; **idea** continue to work for the new stuff in C+=
+ like classes.
<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt; It is not full compatibility if there exist printf fo=
rmat strings that
<br>&gt;&gt; &gt;&gt; do
<br>&gt;&gt; &gt;&gt; not function with std::putf. We discussed something a=
bout how you would
<br>&gt;&gt; &gt;&gt; now
<br>&gt;&gt; &gt;&gt; have to escape curly braces which previously did not =
need escaping. As
<br>&gt;&gt; &gt;&gt; long
<br>&gt;&gt; &gt;&gt; as these specifiers exist, you do not have compatibil=
ity.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; But nobody has suggested that there would be any such iss=
ues. You don't
<br>&gt;&gt; &gt; have
<br>&gt;&gt; &gt; to escape curly braces because curly braces are not used.=
 I don't even
<br>&gt;&gt; &gt; know
<br>&gt;&gt; &gt; where you're getting the idea that curly braces are part =
of any such
<br>&gt;&gt; &gt; proposal.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Further, the N3506 proposal specifically states that you =
can not
<br>&gt;&gt; &gt; mix-and-match positional arguments with traditional print=
f arguments. So
<br>&gt;&gt; &gt; a
<br>&gt;&gt; &gt; string that is a legitimate `printf` format will produce =
the same
<br>&gt;&gt; &gt; results
<br>&gt;&gt; &gt; with `putf`.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Personally, I think it is unnecessary to separate the two=
, since "%n$"
<br>&gt;&gt; &gt; and
<br>&gt;&gt; &gt; "%n%" are both invalid for printf. Since such syntax woul=
d break with
<br>&gt;&gt; &gt; `printf`, there's no harm in allowing it to have a meanin=
g with `putf`.
<br>&gt;&gt;
<br>&gt;&gt; FWIW, %n$...c is valid for printf, and has the same meaning as=
 in this
<br>&gt;&gt; proposal:
<br>&gt;&gt; <a href=3D"http://pubs.opengroup.org/onlinepubs/9699919799/fun=
ctions/printf.html" target=3D"_blank">http://pubs.opengroup.org/<wbr>online=
pubs/9699919799/<wbr>functions/printf.html</a>
<br>&gt;
<br>&gt;
<br>&gt; Which version of C is this true for?
<br>
<br>Ah, it's just POSIX, meaning everyone except MSVC supports it.
<br>'course, MS made the mistake of specifying that "If a percent sign is
<br>followed by a character that has no meaning as a format field, the
<br>character is copied to the output unchanged."
<br>(<a href=3D"http://msdn.microsoft.com/en-us/library/56e442dc.aspx" targ=
et=3D"_blank">http://msdn.microsoft.com/en-<wbr>us/library/56e442dc.aspx</a=
>) instead of
<br>leaving it undefined, so if we're worrying about them, we couldn't use
<br>the %N% syntax either.<br></blockquote><div><br>Right, but the <i>stand=
ard</i> doesn't have to concern itself with what others defined from undefi=
ned behavior. That is, if you provided a standard-conforming printf format =
to putf, it would work as expected. If you don't, then you get undefined be=
havior from putf.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_5585_2507447.1368673715860--

.

On Wed, May 15, 2013 at 11:08 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> That is, if you provided a
> standard-conforming printf format to putf, it would work as expected. If you
> don't, then you get undefined behavior from putf.

Errr, not quite.  `putf` has no undefined behavior.  Everything not being well
defined in `printf` results in a less feature complete (from the point
of view of
C-printf, but not iomanip) output, or a failbit on the stream.  I consider any
thing not well-defined in `putf` as a bug (it makes no sense to have UB
in a string formatting facility, seriously).

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_389_14437684.1368685011305
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, May 15, 2013 9:54:14 PM UTC-7, Zhihao Yuan wrote:
>
> On Wed, May 15, 2013 at 11:08 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > That is, if you provided a
> > standard-conforming printf format to putf, it would work as expected. If
> you
> > don't, then you get undefined behavior from putf.
>
> Errr, not quite.  `putf` has no undefined behavior.  Everything not being
> well
> defined in `printf` results in a less feature complete (from the point
> of view of
> C-printf, but not iomanip) output, or a failbit on the stream.  I consider
> any
> thing not well-defined in `putf` as a bug (it makes no sense to have UB
> in a string formatting facility, seriously).
>

OK, I said that wrong, so let me rephrase.

If you have a standard-conforming printf formatting string, then `putf`
will accept it and do the same thing. If your format string wasn't
standard-conforming, then there's no guarantee of what printf will do. So
`putf` doesn't need to accept it.

--

---
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_389_14437684.1368685011305
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, May 15, 2013 9:54:14 PM UTC-7, Zhihao Yuan wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">On Wed, May 15, 2013 at 11:08 PM, Nicol Bo=
las &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
u13Zde5miskJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; That is, if you provided a
<br>&gt; standard-conforming printf format to putf, it would work as expect=
ed. If you
<br>&gt; don't, then you get undefined behavior from putf.
<br>
<br>Errr, not quite. &nbsp;`putf` has no undefined behavior. &nbsp;Everythi=
ng not being well
<br>defined in `printf` results in a less feature complete (from the point
<br>of view of
<br>C-printf, but not iomanip) output, or a failbit on the stream. &nbsp;I =
consider any
<br>thing not well-defined in `putf` as a bug (it makes no sense to have UB
<br>in a string formatting facility, seriously).
<br></blockquote><div><br>OK, I said that wrong, so let me rephrase.<br><br=
>If you have a standard-conforming printf formatting string, then `putf` wi=
ll accept it and do the same thing. If your format string wasn't standard-c=
onforming, then there's no guarantee of what printf will do. So `putf` does=
n't need to accept it.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_389_14437684.1368685011305--

.

------=_Part_4700_7418998.1368700225387
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, May 14, 2013 11:10:28 PM UTC+1, Nicol Bolas wrote:
>
> On Tuesday, May 14, 2013 12:09:55 PM UTC-7, Jonathan Wakely wrote:
>>
>> What's the point of %s vs. %d?   In the typesafe printf example in
>> http://www.generic-programming.org/~dgregor/cpp/variadic-templates.htmlthe conversion specifier is completely ignored, you can say printf("%s %d",
>> 1, "two") and it works correctly.
>
>
> I assume you're using the word "correctly" very loosely, since "%08x"
> doesn't work at all.
>

But my example didn't use any flag, width or precision, and works
correctly, in whatever sense you like.


> N3506 would have allowed that to work.
>

So could another syntax that supports precisions.

I thought it was obvious that I wasn't suggesting the toy printf example
from the initial variadic templates paper is a suitable replacement for
std::putf or std::printf, I was just pointing out that printf-style
formatting includes a redundant conversion specifier.




> So *that* is the point of those specifiers: they allow you to provide
> formatting information.
>

--

---
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_4700_7418998.1368700225387
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, May 14, 2013 11:10:28 PM UTC+1, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On Tuesday, May 14, 2013 12:09:55 P=
M UTC-7, Jonathan Wakely wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">What=
's the point of %s vs. %d? &nbsp; In the typesafe printf example in <a href=
=3D"http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html=
" target=3D"_blank">http://www.generic-<wbr>programming.org/~dgregor/cpp/<w=
br>variadic-templates.html</a> the conversion specifier is completely ignor=
ed, you can say printf("%s %d", 1, "two") and it works correctly.</blockquo=
te><div><br>I assume you're using the word "correctly" very loosely, since =
"%08x" doesn't work at all.</div></blockquote><div><br>But my example didn'=
t use any flag, width or precision, and works correctly, in whatever sense =
you like.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>=
 N3506 would have allowed that to work.<br></div></blockquote><div><br>So c=
ould another syntax that supports precisions.<br><br>I thought it was obvio=
us that I wasn't suggesting the toy printf example from the initial variadi=
c templates paper is a suitable replacement for std::putf or std::printf, I=
 was just pointing out that printf-style formatting includes a redundant co=
nversion specifier.<br></div><div><br><br>&nbsp;</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div>So <i>that</i> is the point of those specifier=
s: they allow you to provide formatting information.</div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4700_7418998.1368700225387--

.