I have no idea what you mean by dynamic_cast working with "types" not "values".
I am sure to do: Foo& foo = dynamic_cast<Foo&>(moo); Foo& foo = const_cast<Foo&>(moo); same instance, different type.
static_cast<float>(1000000000u) drastically changes the representation and the type,
Yes, for static_cast I'll give you that. However, it is not static_cast *own* quality as it simply piggy-backs on the built-in *language* support for conversions between *related* types. That way, static_cast is nothing more but syntactic sugar as "float foo = 10u" will just do.
just like lexical_cast<float>("1000000000") does.
lexical_cast is different as it's not jusr sugar-coating and "float foo = "10" " wil not take you anywhere. Therefore, if we have to find the closest ?_cast that lexical_cast looks like, then, I'd choose reinterpret_cast -- conversions between *unrelated* types. And I am personally not exactly comfortable with that comparison as I do not see it serving any useful purpose. All in all, these language-supported casts behave *differently* -- the purpose is the paramaunt. It is arguable if their visual similarity is beneficial or a hindrance (the user still need to understand their differences and usage subtleties). Now lexical_cast steps in and seemingly sactifices usefulness/purpose for appearance. Not the right choice is you ask me (you obviously are free to disagree).
And optional<> is not that strange.
To start with "strangeness" is subjective. And that is last of my worries. I thought I voiced my reasons against it -- it still requires the default-constructability. I work with quite complex classes which happen not to have the default constructor. Second, IMHO lexical_cast is seemingly straightforward (easy to grasp for a casual user). Throwing optional<> into the mix does not seem justified (that's surely subjective unlike the default-constructability).
Or, using the helper:
int i = lexical_cast<optional<int> >(mystring).get_value_or(-1);
Why is this so bad?
Well, if you want lexical_cast (and Boost) *not* used in the wide, then keep mounting these wonderful complexities and interfaces. Surely the users will be very supportive of your effort. Best, V.