> The inconsistency is in some sense hard to evaluate because, as
> mentioned, the original paper did not specify the purpose of
> to_string().

That's true.  In order to overcome this, I think that your proposal
would benefit from putting a discussion at the beginning what purpose
you want the (new) function to serve.  I'm opting for "having something
simple to show a 'nice' string to humans" but you might disagree.
Without defining a use-case for this function, any further decision will
be debatable because, as you say, there is no solution that seems right
for all cases.

> hexfloat is by my understanding available through options 'a' and 'A'.

You are right.  I didn't realize that.

> Generally speaking if a developer has created an application relying
> on a standard guaranteed behaviour, any change can be a breaking one
> (here for example one could be assuming that the result does not
> contain character 'e'). Especially the silent runtime behaviour change
> is potentially hazardous.

I would consider any software that uses `to_string` (as specified today)
for data exchange with another application or for internal textual
storage flawed.  I don't think that this should restrict us too much in
thinking about ways to improve the standard library.  Better fix a
broken tool now than carrying it along (even if deprecated) for years to
come.  The beauty of the `to_string` family of functions really shows in
generic code and it would be a pity if we had to special-case
floating-point every time.  It is already too bad the the parsing
functions all have different names instead of being generic in the form
`from_string<T>` but I believe I have seen a proposal to address this.

I would prefer to keep the `to_string` functions *simple* tools for
presenting numbers to humans in a "reasonable" format.  It is true that
"reasonable" is hard to define but the standard already did this long
time ago when specifying `%g` so it seems logical to me to re-use this
definition instead of inventing a new one.  If an application needs
finer control, it can always use `sprintf` directly with all the
flexibility it offers.  (Or you can use streams if you prefer.)

> Why the (direct) use of exceptions such as std::invalid_argument does
> not seem appropriate is that it seems a bit too severe a consequence
> that failing to create a string would in practice often crash the
> application; i.e. people would forget to use try-catch with
> to_string().  It's not a serious error if conversion fails as the
> function can simply report "I got garbage, I can't give an answer and
> you can check this from the return value if interested".  If the
> failure is a serious error for the application, it should handle it
> accordingly.

I think that passing an invalid format specifier is a bug and the
function should fail as loudly as possible in that case.  Potentially
crashing the application seems appropriate to me.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/87oaazvz0p.fsf%40gmail.com.

.

------=_Part_4328_891621905.1456807094953
Content-Type: multipart/alternative;
 boundary="----=_Part_4329_486874345.1456807094953"

------=_Part_4329_486874345.1456807094953
Content-Type: text/plain; charset=UTF-8

On Monday, February 29, 2016 at 7:10:36 PM UTC-5, Moritz Klammler wrote:
>
> > Generally speaking if a developer has created an application relying
> > on a standard guaranteed behaviour, any change can be a breaking one
> > (here for example one could be assuming that the result does not
> > contain character 'e'). Especially the silent runtime behaviour change
> > is potentially hazardous.
>
> I would consider any software that uses `to_string` (as specified today)
> for data exchange with another application or for internal textual
> storage flawed.


Flawed or not, I don't think it's reasonable to *dismiss* this use-case.
Reality has taught us that people will use the simplest tool available to
them that seemingly does the job, without looking too closely at it.
`to_string` became the simplest way of turning a float into a string.
Therefore, people have and will use it for *every* form of turning a float
into a string.

That's not to say we shouldn't just change the behavior, even if it causes
breakage. But we shouldn't ignore the fact that it will cause breakage; we
can't just declare that these users are *wrong* for using the tool we made
for them. The standards committee was the one who was wrong here, for
creating a simple tool without any real direction in what it means or how
it should be used.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/330c295f-5796-48f5-bb77-f39f023de632%40isocpp.org.

------=_Part_4329_486874345.1456807094953
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, February 29, 2016 at 7:10:36 PM UTC-5, Moritz K=
lammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Generally s=
peaking if a developer has created an application relying
<br>&gt; on a standard guaranteed behaviour, any change can be a breaking o=
ne
<br>&gt; (here for example one could be assuming that the result does not
<br>&gt; contain character &#39;e&#39;). Especially the silent runtime beha=
viour change
<br>&gt; is potentially hazardous.
<br>
<br>I would consider any software that uses `to_string` (as specified today=
)
<br>for data exchange with another application or for internal textual
<br>storage flawed.</blockquote><div><br>Flawed or not, I don&#39;t think i=
t&#39;s reasonable to <i>dismiss</i> this use-case. Reality has taught us t=
hat people will use the simplest tool available to them that seemingly does=
 the job, without looking too closely at it. `to_string` became the simples=
t way of turning a float into a string. Therefore, people have and will use=
 it for <i>every</i> form of turning a float into a string.<br><br>That&#39=
;s not to say we shouldn&#39;t just change the behavior, even if it causes =
breakage. But we shouldn&#39;t ignore the fact that it will cause breakage;=
 we can&#39;t just declare that these users are <i>wrong</i> for using the =
tool we made for them. The standards committee was the one who was wrong he=
re, for creating a simple tool without any real direction in what it means =
or how it should be used.<br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/330c295f-5796-48f5-bb77-f39f023de632%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/330c295f-5796-48f5-bb77-f39f023de632=
%40isocpp.org</a>.<br />

------=_Part_4329_486874345.1456807094953--
------=_Part_4328_891621905.1456807094953--

.

------=_Part_6628_1089625543.1456956883718
Content-Type: multipart/alternative;
 boundary="----=_Part_6629_1779060161.1456956883719"

------=_Part_6629_1779060161.1456956883719
Content-Type: text/plain; charset=UTF-8

@ Moritz Klammler

So far I've seen no good arguments why to_string() should use something
else than round-tripping precision, but luckily that doesn't mean the
result would be hard to read: in many (common) cases the result will/should
be identical to what %g produces and be way better than the result of %f.
Sure there will be cases where it means more characters than with %g, but
as demonstrated with the time_t-example, 6 significant digits is not
enough; trading correctness for vaguely defined readability is like trading
correctness for performance. What's the point of evaluating readability of
string representation that misses essential information of the source
value? What comes the 6 digits, I don't know the history but the decision
seems strange: with uint32 number of significant digits goes up to 10 and
with uint64 up to 20, why should 6 be enough for floating points?

The need to create wrappers for various functions in order to be used in
templates is indeed an annoyance as is the idea that the standard would
introduce more reasons to write such wrappers, so from that point of view I
agree that maintaining to_string() would be desirable. And speaking of
templates, it's a good example why to_string<T> should have well defined
and from that point of view identical behaviour for all T.

One can easily come up with realistic examples why passing invalid
arguments to to_string_f() is not a bug, but if the conventions in the
standard would still insist on using exceptions in situations like this,
which I hope it doesn't, then it must be so. I'll have to look into that
more closely.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1caa2a-4e6d-4673-962a-1957533410dc%40isocpp.org.

------=_Part_6629_1779060161.1456956883719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@ Moritz Klammler<br><br>So far I&#39;ve seen no good argu=
ments why to_string() should use something else than round-tripping precisi=
on, but luckily that doesn&#39;t mean the result would be hard to read: in =
many (common) cases the result will/should be identical to what %g produces=
 and be way better than the result of %f. Sure there will be cases where it=
 means more characters than with %g, but as demonstrated with the time_t-ex=
ample, 6 significant digits is not enough; trading correctness for vaguely =
defined readability is like trading correctness for performance. What&#39;s=
 the point of evaluating readability of string representation that misses e=
ssential information of the source value? What comes the 6 digits, I don&#3=
9;t know the history but the decision seems strange: with uint32 number of =
significant digits goes up to 10 and with uint64 up to 20, why should 6 be =
enough for floating points?<br><br>The need to create wrappers for various =
functions in order to be used in templates is indeed an annoyance as is the=
 idea that the standard would introduce more reasons to write such wrappers=
, so from that point of view I agree that maintaining to_string() would be =
desirable. And speaking of templates, it&#39;s a good example why to_string=
&lt;T&gt; should have well defined and from that point of view identical be=
haviour for all T.<br><br>One can easily come up with realistic examples wh=
y passing invalid arguments to to_string_f() is not a bug, but if the conve=
ntions in the standard would still insist on using exceptions in situations=
 like this, which I hope it doesn&#39;t, then it must be so. I&#39;ll have =
to look into that more closely.<br></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/be1caa2a-4e6d-4673-962a-1957533410dc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/be1caa2a-4e6d-4673-962a-1957533410dc=
%40isocpp.org</a>.<br />

------=_Part_6629_1779060161.1456956883719--
------=_Part_6628_1089625543.1456956883718--

.

------=_Part_1166_1091494614.1456961258121
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, 3 March 2016 06:14:43 UTC+8, u97...@gmail.com  wrote:
> @ Moritz Klammler
>=20
> So far I've seen no good arguments why to_string() should use something e=
lse than round-tripping precision, but luckily that doesn't mean the result=
 would be hard to read: in many (common) cases the result will/should be id=
entical to what %g produces and be way better than the result of %f. Sure t=
here will be cases where it means more characters than with %g, but as demo=
nstrated with the time_t-example, 6 significant digits is not enough; tradi=
ng correctness for vaguely defined readability is like trading correctness =
for performance.=20

I agree entirely. It's not possible to separate the use cases of data inter=
change and human readability; textual interchange formats are mostly read b=
y machines but are also monitored and in some cases edited by humans. Anoth=
er example would be logging; usually log files are ignored, occasionally th=
ey are read (by humans) and occasionally a human will need to feed the logg=
ed values back into the program and be confident of getting the same behavi=
or.=20

Currently I use Milo Yip's implementation of Florian Loitsch's Grisu2 algor=
ithm (https://github.com/miloyip/dtoa-benchmark/blob/master/readme.md), but=
 it would be great to be able to use a standard facility instead.=20

This would mean that to_string couldn't be specified in terms of printf for=
mat specifiers, but I don't see that as much of a problem - those were stan=
dardized before the utility of perfect representation was understood.=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2500669f-40ee-4027-8557-648815a6347e%40isocpp.or=
g.

------=_Part_1166_1091494614.1456961258121--

.