Why a new pointer type? Why not just extend RTTI?

If you've read through the whole paper, it doesn't do much to say why a new pointer type is being proposed as a viable solution to the different motivations for the paper (see my other post about rich pointers for background). It does mention some hints that bear repeating and pointing out:

• We don't want users to pay for what they don't use -- more precisely, we only want the compiler to generate the type descriptors for types that are used through rich pointers.
• We don't want to break existing code that rely on normal pointer semantics that's why we didn't go about changing how pointers work. Backward compatibility is important.
• We don't want to tack the implementation onto existing runtime type information (RTTI) for backward compatibility. There's code out there that has been built and linked to rely on std::type_info being a certain size and layout -- changing this on newer libraries/binaries will cause ABI compatibility issues that we don't want to introduce.

Why not just a smart pointer with an assist from the compiler to generate the descriptors?

This may be feasible and as the paper points out there is a way of achieving this. Unfortunately the following cannot be guaranteed by a library-only implementation:

• Deterministic runtime registration of types from libraries. There's currently no way to ensure that a rich_ptr will be able to contain the pointer to the correct type especially if the source is a normal pointer.
• Deterministic invalidation of already-registered types. There's no cross-platform and standard way for registering new types in an application's runtime that also guarantees that there's only one definition of a type, and that objects of that single type can be referred to using the correct pointer type.
• Clear upgrade path from one version of a type to the latest version of the type. Similar to the above point, there's no clear and cross-platform way of doing this.
• Automatic and selective generation of complete types and those types it depends on in its definition. Even with a compiler assist, making this happen with a normal template class and the type for this given template is far too much work for the compiler as opposed to having the compiler treat rich pointers as a special type of pointer.

Why use the '%' character and not another character (like '^' or '@')?

There's really no strong reason to use %, but there are reasons to reject '^' and '@'. The caret character ('^') although ideal to use similar to how Pascal pointers work, unfortunately is already used by Microsoft in their proprietary C++/CLI implementation. Not chosing the caret was an obvious decision to avoid the potential clash and objections with this extension to standard C++. The at character ('@') although has been used in the Ruby programming language, isn't a special symbol (nor a valid symbol) in C++ -- making @ a valid operator character opens up potential major surgery for current compilers and the grammar. In contrast, the percent character ('%') is already a valid symbol and operator in C++ that has a binary operator counterpart -- this is symmetric with the asterisk ('*') which is both a unary and binary operator version.

I personally would also like to think that the percent symbol denotes the presence of two things on different sides of the common line -- a pointer that refers to an object (top circle) and the type descriptor (bottom circle). Of course this is a mnemonic device and symbolism that's very far from existing practice and usage of the percent operator (as a modulo operator), I'd like to think I tried to give it some meaning that's relevant. ;)

Is there an implementation available?

Short answer: Not yet.

Long answer: If the committee agrees that this is something worth exploring, I'm very much poised to go ahead and implement it as an extension to the Clang compiler front-end. At this time the proposal is meant to spark discussion as to whether it's something the members of the committee (and the users) will want to see in the language. Practically speaking, there's no point in going forward with an implementation if people don't think the original idea is worth implementing in the language anyway.

Conclusions

The Kona meeting is exactly two weeks away and I'm going to be preparing more materials for presentation among the members of the committee. I'll also be reading the other papers that are in the pre-Kona meeting to prepare for the discussions that I definitely want to be contributing to in the meetings. You can also expect that I will be writing about the meeting afterwards and will be keeping notes as the meetings go on.

I'm definitely looking forward to the meeting -- if you're going, I do hope to see you there. If you're not going and would like to send your feedback on any of the papers and aren't on the committee mailing lists, please feel free to send in your comments either through the comment form or through email.

Thanks for reading this far and I do hope this helps!