On 5/5/05, Dave Dribin <dave-ml@dribin.org> wrote:
On May 3, 2005, at 3:27 AM, Kevlin Henney wrote:
In message <8dee398f92d54b9e2f27e107ee73052c@dribin.org>, Dave Dribin <dave-ml@dribin.org> writes
On May 1, 2005, at 1:56 PM, Kevlin Henney wrote:
This issue of providing a default value in case of failure was discussed in the early days of lexical_cast, but not included. In fact, if you go back far enough, opting for the default or zero constructed value of the target rather than throwing an exception was the original behaviour.
However, the accommodation of an additional argument was not included in lexical_cast in part for the simple reason that it ceases to look like a cast and in part because once you start down that road there are a number of additional arguments and options that you might want that are "reasonable". It was felt that much of this would be better off in a general conversions library that had no pretensions to being cast-like.
I agree that the default behavior should throw an exception. It just seems silly to create a whole new library that could be done in an existing one with about 5 lines of code. And I'd prefer a multi-argument cast-like function than include yet *another* 3rd party library with my application. Anyhow, I have an idea or two as alternatives. If you're interested, lemme know, otherwise I'll drop the whole idea. :)
I'd be interested to hear your ideas.
Since it sounds like the main argument against adding a second argument is that it is no longer cast-like, the simplest idea is to rename lexical_cast so it is no longer cast-like. I was thinking convert_to would be nice and readable:
int n = convert_to<int>("abc"); // Should throw an exception... bad_conversion? int n = convert_to<int>("abc", 0); // Should return 0
string s = convert_to<string>(5);
The main issue with renaming, obviously, is backward compatibility. Of course, there's no need to remove lexical_cast right away, or at all, even. Maybe make it deprecated, or at least implemented in terms of convert_to.
Thoughts?
-Dave
As an early whiner about issues of lexical_cast, I've seen these issues discussed many times. A few years ago there was a nice proposal/implementation of an extensible lexical_cast that could use other, more optimal, choices for certain conversions (http://lists.boost.org/MailArchives/boost/msg34342.php unfortunately the code seems to have been lost). lexical_convert was bandied about as a name for something providing default values, but I really like the name convert_to. This is a library I'd really like to see in boost.