Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013

Subject: Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-24 23:13:43

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.