Re: [c++-concepts]: constraint association

[Andrew Sutton <andrew.n.sutton@gmail.com>]

> | Agreed. But without some source-level annotations in the tree, I don't
> | think I can generate the diagnostics that programmer's might otherwise
> | expect. I'd have to emit the internal representation.
>
> Do you have examples where we don't do or we can't do the obvious thing
> in terms of diagnostics?

I think we'll have this problem anywhere we want to pretty-print a
template parameter that's declared using the concept shorthand. I'll
have a better feeling for the issue once I start working the shorthand
in.

> | If those constraints are cached, I don't see any other place to put
> | them except in the template info.
>
> Exactly.

Previous discussion seemed to indicate that saving constraints with
template decls was preferable.

> | On the other hand, it seems like the only place we actually need to
> | worry about is with non-template member functions.
>
> Member function of templates are temploids, so no worry there either.
> (Internally, they act and are represented like templates.)

There's a difference between when those declarations are instantiated
and when their constraints really need to be evaluated. Because
temploids are instantiated with a class definition (prior to use), we
(may) need to carry some information with those instances.

The committed version in the branch carries those constraints in
template_info for the temploid. The submitted patch carries the
instantiated constraints with the member declaration. The most recent
version on my work computer doesn't carry any constraints with
temploids -- it instantiates the requirements directly from the
template/args in the declarations' template_info.

> | I think I can just grab the requirements and arguments and check them
> | without caching them in the template_info.
>
> I think we need to remember them for duplicate_decls or other routines
> that either check or use ODR-derived properties.

This doesn't seem to be a problem. IIRC, the instantiated declarations
are differentiated by their template constraints, not their
instantiated constraints.

Differentiating by instantiated constraints may not be viable,
anyways. Especially, if the instantiation folds them to only "true" or
"false".

> | We still don't have nodes specific to TEMPLTAE_DECL or
> | TEMPLATE_PARM_DECL though.
>
> A tree with TREE_CODE equal to TEMPLATE_DECL or TEMPLATE_PARM_DECL is
> just that.  What we do is to use all unused- tree slots.  Or are you
> suggesting we have exhausted all available pre-defined slots on such nodes?

Unknown. I'll have to look.

But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
parameters are either TYPE_DECLs or PARM_DECLs. I think auto
declarations, get VAR_DECLs, but I haven't looked closely at that
design. I'd have to look to see if there are any free tree slots all
of those decl nodes to minimize.

Andrew