This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] add __is_final trait to fix libstdc++/51365
On Tue, Dec 13, 2011 at 10:43 AM, Jason Merrill <jason@redhat.com> wrote:
> On 12/12/2011 09:14 AM, Gabriel Dos Reis wrote:
>>
>> On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini<paolo.carlini@oracle.com>
>> ?wrote:
>>
>>>> I think being able to detect a final class is good enough for now,
>>>> until we find out if there are real problems being encountered as
>>>> people make more use of C++11.
>>>
>>>
>>> Maybe. But in my opinion we should not rush. Something is wrong here at a
>>> more fundamental level.
>>
>>
>> I agree that we should wait a little bit for the dust to settle down.
>> ?Users should
>> avoid it, and implementors shouldn't go through hoops non commensurable
>> with
>> the benefits of "final". ?Maybe the "right" primitive is slightly
>> different.
>
>
> This patch seems pretty simple and safe. ?Are you (Gaby and Paolo) arguing
> that even so, it shouldn't go in?
My comment isn't about the technical aspect of the patch itself -- it
is a simple patch.
But we don't seem to understand yet the implications of "final". As
was observed
on the standard reflectors, the appropriate trait might actually need
to be binary
instead of unary as this patch implements -- for the purpose of empty base
optimization which is where the problems pop up.