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-14 15:06:52

On 14 Nov 2013 at 0:04, Andrey Semashev wrote:

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

Taking off my peer review manager hat:

I see there being a base boost::type_info class, with quirks adapters 
for backwards compatibility deriving from it. Such quirk adapters 
would be extremely thin (basically changing what name() does, and a 
few other minor changes).

Regarding the standard's definition of type_info, that is unimportant 
here except where some boost::type_info_something is declared to 
behave exactly like std::type_info. If we explicitly declare that 
boost::type_info is intended as being superior to the standard and 
therefore a breaking change from it, I see no issue.

Someone will now mention that because boost::type_info derives from 
std::type_info that one cannot safely change its API. And this was 
exactly my original point: a boost::type_info_something capable of 
directly substituting according to the C++ type rules for 
std::type_info MUST replicate as a minimum what the C++11 standard 
says AND what the local implementation std::type_info does, including 
quirks. Otherwise you get the problem that one compiland using 
std::type_info will segfault when it encounters a boost::type_info 
from another compiland which has been auto-converted to 
std::type_info by the compiler.

Quite separately from this is where the programmer intentionally 
replaces std::type_info with boost::type_info and the program 
compiles and executes correctly because boost::type_info has been 
cleverly designed to do so AND the programmer understands what that 
means. That's a compile-time compatible type_info, which is very 
different from a run-time compatible type_info.

Putting back on my peer review manager hat, I'd like to thank the 
list for such a useful debate. It's certainly helped me see aspects 
of the library I had not previously considered. I'll try to produce 
an interim report this weekend to help frame the discussion during 
the last five days of review.

Niall

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