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

[Gabriel Dos Reis <gdr at axiomatics dot org>]

Andrew Sutton <andrew.n.sutton@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