This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR c++/52343 - error with alias template as template template argument


On Mon, Dec 24, 2012 at 7:57 AM, Dodji Seketeli <dodji@redhat.com> wrote:
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> G> On Sun, Dec 23, 2012 at 11:04 PM, Jason Merrill <jason@redhat.com> wrote:
>>> On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
>>>>
>>>>     else if (TREE_TYPE (t)
>>>>            && INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
>>>> -          && !TREE_CONSTANT (t))
>>>> +          && !TREE_CONSTANT (t)
>>>> +          /* Class template and alias template arguments should be OK.
>>>> */
>>>> +          && !DECL_TYPE_TEMPLATE_P (t))
>>>
>>>
>>> Instead, let's add a previous else if to catch template template arguments
>>> (and do nothing) so that when we hit this else if, we know we're dealing
>>> with a non-type argument.
>>
>> Thanks; that would make the logic clearer.  I would suggest that we
>> abstract this series of conjunction into a separate (static inline)
>> function, e.g. nontype_argument_p.
>
> These conjunctions represents a non-type argument only if they are
> satisfied /and/ the previous 'if' branches are not taken.  So just
> putting the conjunctions in e.g, nontype_argument_p could be seen as
> confusion too, IMHO.
>
> Could we just consider that the patch + comment of my earlier message and the
> comment of these conjunctions
>
>    /* A non-type argument of integral or enumerated type must be a
>       constant.  */
>
> should make this less confusing?

I am not sure the suggestion would be confusing, but I am
inclined to do as you suggest.

I do believe though that we should aim for reducing the
size of most of our functions; there are many places where
we replicate verbatim logics that should be abstracted
into separate functions, increasing reuse and coherence,
and decreasing likelihood of bugs

Thanks!

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]