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/