Jason Merrill <[email protected]> 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
