Hi, > So the proposed patch just adds the __is_final intrinsic for use > internally by the library, to allow library changes so the test cases > in the bug report will pass. If preferred I won't even add __is_final > to the extend.texi docs, to leave it as an undocumented extension that > we could more easily remove (or deprecate) later if necessary.
I think this makes absolutely sense. And documenting it seems fine: after all, for better and worse, 'final' itself is in C++11. For the internal library uses, on the other hand, I don't think we should overly document a trait like __is_empty_non_final (essentially an __and_) which, afaics, would usefully replace std::is_empty in various places for 4.7. Paolo
