Andrew Sutton <andrew.n.sut...@gmail.com> writes:
| I the long term, I think we'll end up having constraints attached to
| declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
| Although now that I'm looking, it seems that lang_decl_parm does not
| inherit lang_min. Hmm...
|
| Mostly, though, I'm not sure where I could put it where both
| TEMPLATE_DECL and FUNCTION_DECL would have constraints.
I think we want constraints for:
* FUNCTION_DECL
* TEMPLATE_DECL
* TYPE_DECL
* TEMPLATE_PARM_DECL
Internally, we want to always store the canonical form of a decl, not the
source-level form -- the current g++ AST isn't prepared for that (I wish
it was, but it isn't.) This allows for simple comparison and other
semantics processing.
When we have
void sort(Range& r);
and Range is a unary concept, this make 'sort' a TEMPLATE_DECL. I am
not sure we actually want to make the PARM_DECL 'r' to have a constraint.
Rather, we want the internal representation to store the canonical form:
template<typename __T1> requires Range<__T1>
void sort(__T1& r);
so that the PARM_DECL 'r' never gets a constraint -- it is its type that
is constrained. This way, duplicate_decls for example won't need extensive
surgery to remain unconfused.
-- Gaby
