Jason Merrill <ja...@redhat.com> writes:

> Hmm.  I know I'm the one that suggested this approach, but I think I'm
> uncomfortable with this minimal change, since code for handling
> BOUND_TEMPLATE_TEMPLATE_PARM expects to be able to get a
> TEMPLATE_TYPE_PARM_INDEX out of it, and that won't work for the alias
> template use.

Yes.  Though I thought I'd spot those places if need be (as I was hoping
the code to ICE for these cases) and let them try to access the
TEMPLATE_TYPE_PARM_INDEX only for non-alias template use cases.  Not
elegant, granted.

> So I'd like to rename BOUND_TEMPLATE_TEMPLATE_PARM to something more
> generic, perhaps TEMPLATE_ID_TYPE, that just takes a template and
> args. So existing uses of BOUND_TEMPLATE_TEMPLATE_PARM would be
> replaced with a TEMPLATE_ID_TYPE around a TEMPLATE_TEMPLATE_PARM.
>
> At that point it probably makes sense to replace the use of
> TEMPLATE_ID_EXPR in TYPENAME_TYPE with TEMPLATE_ID_TYPE.
>
> Does this make sense?

Yes it does.

>  Sorry to make more work for you.

No problem.  I wasn't sure I'd be able to "sell" the amount of change
incurred by this kind of "generic" approach in the first place.  It's
great that I don't have to.  ;-)

> Also, rather than pass back unknown_nb_args_p from
> coerce_template_parms, let's make it a predicate next to
> any_dependent_template_arguments_p and then use it in both places.
> And change the name; it took me a little while to realize that "nb" is
> short for "number".

Okay.  I'll look into this.

Thanks.

-- 
                Dodji

Reply via email to