Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-13 15:04:45

On Wednesday 13 November 2013 14:29:07 Niall Douglas wrote:
> On 13 Nov 2013 at 22:46, Andrey Semashev wrote:
> > > Can I suggest this instead: instead of making boost::type_info more
> > > like the flawed std::type_info, can you leave boost::type_info to be
> > > pure and instead add a new boost::type_info_std or something which
> > > does replicate std::type_info's implementation specific quirks?
> > 
> > I don't see the point in such duplication. boost::type_index will only
> > work
> > with boost::type_info anyway.
> 
> There are two primary use cases for boost::type_info: (i) as a better
> (static) std::type_info (ii) as a direct std::type_info substitute
> working with RTTI off.
> 
> What boost::type_info does not currently provide which std::type_info
> does is a method of retrieving the type mangling string with RTTI
> off. It could be easily added if name() can return a std::string, but
> that is outside the scope of this peer review.
> 
> Those use cases are not identical.

Yes, but they also are not exclusive. At least, not with respect to name 
functions.

> I also don't see why my proposal
> to provide both type_info replacements has anything to do with your
> arguments which appear to mostly be based on API purity rather than
> practical concerns. I proposed that boost::type_info be pure and
> fitting your stated wishes, while a new boost::type_info_std (which
> is implicitly convertible to a boost::type_info) is quirky. You get
> what you want, while people wanting a direct drop in perfect
> substitute for std::type_info also get what they want. Trying to get
> boost::type_info to on its own be everything to everybody I don't
> think is wise because the use cases are semantically distinct.

I don't like the idea of having two practically equivalent classes which 
basically do the same thing. The difference between the classes would be in 
the behavior, which is not specified by the standard in the first place and 
can be adjusted in a non-breaking manner in a unified boost::type_info class.