Syntax of get for Variant and any_cast for Any

It took me a little while to figure out that get<T> on a variant is really just
the moral equivalent of dynamic_cast<T> with a funny syntax. I'd like to
understand why, given a variant v, this syntax is used
T* p = get<T>(&v);
T& r = get<T>(v);
instead of this:
T* p = variant_cast

On Mar 10, 2006, at 2:41 PM, Scott Meyers wrote:
It took me a little while to figure out that get<T> on a variant is really just the moral equivalent of dynamic_cast<T> with a funny syntax. I'd like to understand why, given a variant v, this syntax is used
T* p = get<T>(&v); T& r = get<T>(v);
instead of this:
T* p = variant_cast
(&v); T& r = variant_cast (v); [snip] Maybe there are problems to these approaches -- I've hardly investigated them. But I would be interested to know if there is a good reason for the syntaxes for dynamic_cast, any_cast, and get to vary so much.
I think the answer is more archeological than technical :)
We can't overload dynamic_cast, which is too bad: that's the right
name for this sort of thing. If only someone would go ahead and write
the C++0x proposal to add overloading of the cast operators, smart
pointers, any, variant, python::object, and many other classes would
get much more intuitive syntax. But I digress...
any_cast() came around first. It probably should have had the syntax
"T* p = any_cast

Doug Gregor wrote:
We can't overload dynamic_cast, which is too bad: that's the right name for this sort of thing. If only someone would go ahead and write the C++0x proposal to add overloading of the cast operators, smart pointers, any, variant, python::object, and many other classes would get much more intuitive syntax. But I digress...
FWIW, I'm told that the deadline for new language proposals is past, otherwise I'd seriously consider writing up a proposal to add "raw" strings to C++ to make experimenting with regex easier. But *I* digress...
In an ideal world, I think we'd end up using "dynamic_cast" for everything. Instead, we use the name "get", and I think the "any_cast<T>(&a)" is probably a holdover from the dark days that we should change.
My only other knowledge of "get" is from tuple, where "get" takes a compile-time constant, not a type, as an argument. With that background, I found the use of "get" for variant initially confusing. I think it'd be better to find a name with the "_cast" suffix and to explicitly specify pointer and reference types (as with dynamic_cast) and adopt that convention. I don't know enough about the various Boost libraries to know whether that is a reasonable suggestion. Scott

Doug Gregor
We can't overload dynamic_cast, which is too bad: that's the right name for this sort of thing.
Maybe; I'm not so sure. xxx_cast implies capability that you probably wouldn't get from variant, like the ability to tell if some base class of the currently-stored type were available. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams
-
Doug Gregor
-
Scott Meyers