Kevlin, Thank you for your prompt reply. Much appreciated.
I haven't been following the discussion, so would it be possible for you to provide some context/background?
To see all opinions expressed the discussion could be found at http://groups.google.com/group/boost-developers-archive/browse_thread/thread... The description of my suggestion/request is as follows: boost::lexical_cast is very important to me and I use it quite a bit. Possibly due to specifics of my task I constantly struggle with two things: 1. It throws an exception if/when conversion fails (which is not an exceptional situation); 2. It requires the 'Target' class to be default-constructible (many of my classes do not have). I'd like to suggest extending (no disruption to the existing interface/users) the existing template<class Target, class Source> Target lexical_cast(Source const& arg) interface with template<class Target, class Source> Target lexical_cast(Source const& arg, Target const& default_value) The behavior of the latter would be to return the 'default_value' if/when the conversion fails. That communicates the fact of the conversion failure differently (without an exception thrown) as IMHO a conversion failure is not really that exceptional (rather common). The usage would be something like: int value = boost::lexical_cast(some-string, -1); if (value == -1) conversion failed. In fact, my usage pattern is such that I often do not even check the success of the conversion -- if the conversion fails, the supplied failure/default value is returned/used and proceeded with. Equally importantly, the requirements of the proposed/extended lexical_cast would be looser -- no need for the default-constructability of the Target, only the copy-constructability. That proposed/additional lexical_cast interface would be implemented something like if(interpreter << arg) { Target result(failure_value); if (interpreter >> result) return result; } return failure_value; as opposed to the current lexical_cast implementation: if(interpreter << arg) { Target result; if (interpreter >> result) return result; } throw_exception(bad_lexical_cast(typeid(Source), typeid(Target))); return Target(); // normally never reached (throw_exception) I am not sure how much value such an interface extension might have community-wide (although a few people on the list expressed their support) but for our deployment the benefit would be quite substantial as the majority of our classes are with no default constructors. That's been a serious stumbling block for us adopting lexical_cast as-is (I had to write a replacement). Having to provide the default constructor for such classes is a huge hassle for the developer and wide-open for eventual abuse/confusion. Having to handle bad_lexical_cast exceptions is in all honesty quite a hassle (with my usage pattern) and probably not exactly justified as there is nothing exceptional about failed conversion (more like I could not open a file)... not to mention that for whatever guided/misguided reasons exceptions are virtually banned for our mission-critical development. Thank you for your consideration. Looking forward to hearing from you. Best, V.