On 25/11/2013 16:01, Quoth Andrey Semashev:
· In my opinion Antony ought to make TypeIndex v3 quite literally a very lightweight container of some unknown, but known to be uniquely identifying for some type, static const char * string. I think its class type and its list of member functions ought to be deliberately compile-time incompatible with std::type_info to force authors to upgrade their code. A conversion member function ought to be able to synthesise a corresponding std::type_info using typeid() from some boost::type_index<T>, but that’s about it. I would even, personally speaking, go so far as to only provide a boost::type_index and no corresponding boost::type_info, especially if the boost::type_id<T>() function can return a const boost::type_index<T>& and therefore can be used as a static const lref, or copy constructed from it etc.
That's an unexpected turn. If boost::type_id<T>() returns a reference to a non-copyable object then it is useless for me because the essential advantage of type_index is its value semantics. And in such a design boost::type_index has very different semantics from std::type_index, so it shouldn't be named as such to avoid confusion. I would vote against accepting such design.
If you are willing to follow that design then I'd like to ask you to rename the library and the type_index type to avoid the confusion and move all types and functions into the specific library namespace.
I'm fairly sure what Niall was proposing was a copyable object -- ie. basically the same semantics as the current proposed boost::type_index but storing data directly within rather than via indirection to boost::type_info, which would no longer exist. That sounds like a reasonable design to me. (It does mean code using the address-of-type_info as a key would have to change to use value-of-type_index instead, but that's probably safer anyway.) Although:
Caching the name internally as a static member complicates the design (the cache has to be thread-safe and be accessible in global constructors/destructors). Caching the name as a regular member is unacceptable bloat (people expect type_index to be as light as a pointer to type_info; no dynamic memory allocation and associated possible exceptions are allowed).
That does raise a good point.