On 13/11/2013 20:22, Quoth Antony Polukhin:
Names have "_rtti_only" to warn user that this call requires RTTI. This must ring a bell and user may switch to type_id<D> version, which is more portable. type_id_rtti_only is more explicit, so I like it more. But if there'll be many recomendations during review period to switch names to boost::type_id, I'll do that. [...] Names were given according to the following logic: * TypeIndex library promises that it works without RTTI * calls that do not work without RTTI must be explicitly marked * calls that do work without RTTI - is just what was promised by the library, no need to explicitly mark that the call does not requires RTTI
Couldn't this be resolved by changing the first to "TypeIndex library promises to be an enhanced implementation of standard typeid". Then you could just use: * boost::type_id<Type>() // typeid(Type) * boost::type_id(variable) // typeid(variable) Both would work with or without RTTI but the second would only report the declared type of the variable in the absence of RTTI (which is what typeid does for sliced value types anyway). Granted that you're no longer being explicit about RTTI safety or not in the actual method name, but I would hope that library authors who wish their libraries to work either way would test accordingly, so it should not matter. It seems to me that you're already aiming "higher" than bare-bones no-RTTI support with this library, with the name demangling and cv-preservation features for example. (Though please see my other reply regarding demangling.)