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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-25 00:02:26

On Monday 25 November 2013 17:13:43 Gavin Lambert wrote:
> 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.

If so, that implies that copying type_index would be inefficient. I don't 
think this is a reasonable tradeoff. After all, type names is just one 
feature. In the motivating use case (a key in an associative container) type 
names are not needed and the proposed design would result in considerable 
overhead.