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 01:23:12

On Monday 25 November 2013 00:44:30 Niall Douglas wrote:
> On 25 Nov 2013 at 7:01, Andrey Semashev wrote:
> > 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.
> I'm not sure how you got this from my words. No one ever claimed that
> my proposed boost::type_id<T>() would return an uncopyable object -
> it returns a const boost::type_index<T>& to a statically constructed
> instance. One can use the static instance lref directly, take its
> address, or make a copy like std::type_index can. Under my design, a
> boost::type_index<T> has sizeof=0 and merely contains a statically
> constructed const char * shared by all instances. As it is zero
> sized, it is therefore POD.

Sorry, I completely missed the part where type_index become a template. My 
comments were made under impression that boost::type_index is not a template 
and thus cannot have no members and be copyable.

So now it does not erase the type and cannot be used as a key in a container. 
By all measure it is now a completely different beast than std::type_index, so 
please, change the naming.

<nitpicking>And its size is not zero anyway.</nitpicking>

> > > Bear in mind that user code can always subclass boost::type_index and
> > > add
> > > their own name() implementation based on one or more of the above new
> > > member functions.
> > 
> > I don't think that mangled_name() (the last function that returns the
> > cached mangled name) is a good idea. Requiring reimplementation of some
> > particular mangling schemes (and by the way, why these specific ones?) is
> > an unnecessary burden on the author (and maintainer later).
> 
> There is no need to reimplement any mangling schemes. For the MSVC
> and Itanium mangling schemes you simply chop the front and end off
> what is returned by __FUNCSIG__ or __FUNCTION__ and voila, there is
> your correct mangling.

And what about other platforms? Throwing an exception unconditionally doesn't 
look like a portable solution.

> > 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).
> 
> unique_name() uses no dynamic memory and won't throw. That's your
> only guarantee. If you want more functionality, you agree to pay its
> price.

My concern was related to mangled_name(), which you documented as returning a 
reference to a cached std::string.

> Under what I proposed type_info permanently goes away. You get what
> TypeIndex provides and it's up to you if you want to interoperate
> with std::type_info. I proposed this because several reviewers felt
> that type_info implies some relation to std::type_info. I personally
> think that's daft, but that's not my role here - I am here to help
> reach consensus, so I tried to disappear anything called type_info.

boost::type_info is not a problem by itself, as far as I understood the 
reviews. The problem was the hack through which it was implemented in the 
proposed library and the discrepancies with std::type_info. Remove these two 
issues and boost::type_info becomes a type quite useful for portability.

> > I stand by the three functions we discussed during the review:
> > 
> > // Returns std::type_info::name()
> > const char* name() const noexcept;
> > // Returns some low-level (possibly mangled) name
> > const char* raw_name() const noexcept;
> > // Returns some possibly human readable name
> > std::string pretty_name() const;
> > 
> > I'll add that I still think that the first one is required (at least, for
> > compatibility with std::type_index) and has ho have exactly that
> > semantics.
> 
> At least four people objected to name() returning anything different
> to what std::type_info::name() does.

And that's what I suggested, isn't it?