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: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-13 02:47:35

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