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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-13 14:29:07

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. 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.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/