> From: Jeff Garland [mailto:jeff@crystalclearsoftware.com]
> > although the archive seems to handle some threads
> incorrectly, i read
> > through the mentioned messages and there are several
> requests for this
> > simple change and there are no serious concerns. the only
> question is
> > whether to make it a new function to_string or to specialize
> > lexical_cast for std::string.
>
> I think you're right.  And I think things seemed to be
> leaning towards to_string.  I happen to
> prefer it -- it is used extensively in GDTL.

One obvious advantage of to_string is that it is non-intrusive to lexical_cast, however, most people also seemed to agree that it would be a shame to leave lexical_cast as is, with awkward (erroneous?) behavior that makes it unusable in some situations. Personally I'm very much in favor of alternatives that add expressive power and code clarity, so my vote would definitely go to fixing lexical_cast *and* providing to_string.

[Jan Langer]
> > so why isn't it done?
> >
> > is there more need for discussion or is there no one who
> wants to do the
> > actual work? or does it need a formal review ;-) ?

Well, this is not the only issue, and it's not as trivial as it would seem. Solving the std::string problem would be easy with partial specialization, but that would effectively cut off quite a few current and potential lexical_cast users. I've started working on a traits solution that would allow for extension (for example, when using a custom allocator for basic_string, or proprietary string classes), and doesn't need partial specialization (it also incorporates solutions to the other issues). I'm currently swamped, but if there's interest I'll upload it in a week or two, maybe giving the discussions something more concrete to revolve around.

Although the other issues that have been discussed don't necessarily have impact on this change (but to some extent, they do), it would be convenient to bundle some (or all) of them together. >From the top of my head, here are some other opportunities for improvement that we have been discussing:

* A non-throwing version of lexical_cast (lexical_conversion)
* Correct stream precision depending on floating point type (currently default, which is 6)
* to_string convenience function
* to_wstring convenience function
* Support for wide strings and streams
* Automatic detection of base (just read a note with an easy cure - nice!)

Bjorn Karlsson