On Tue, Dec 13, 2011 at 12:02 PM, Jonathan Wakely <jwakely....@gmail.com> wrote: > On 13 December 2011 17:01, Paolo Carlini <pcarl...@gmail.com> wrote: >> Hi, >>> >>> This patch seems pretty simple and safe. Are you (Gaby and Paolo) arguing >>> that even so, it shouldn't go in? >> >> As far as I'm concerned, definetely not! I also think that it would be great >> if, for 4.7, Jon could handle the library issues with EBO by exploiting it. > > Yes, if this goes in for 4.7 I will definitely follow it with the > library changes to make use of it. > >> I only meant to say that something seems to me more fundamentally wrong at >> the design level about 'final' vs EBO, my hope is that for 4.8 we'll have a >> longer term stable solution based on a ISO Committee position. > > In one of the earlier bug report comments I proposed a > __gnu_cxx::is_final<T> library trait to expose the __is_final(T) > intrinsic for users, but decided against it precisely because I don't > know how the committee will want to deal with the issue longer term. > > 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.
Leaving __is_final undocumented is probably a good compromise.
