* We have to avoid increasing memory consumption for regular C++ codes that do not use concepts lite. This is an important criteria. We have only one front-end that is invoked in C++03, C++11, C++14, and C++17 modes. Almost all existing codes are C++03, C++11, and even C++14 only and don't use concepts lite.
| > | 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. Maybe it will help if we have concrete situations to work from. | > | 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. Yes; exactly. | > | 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. Yes, member *declarations* are almost always instantiated as part of the class instantiation. | The committed version in the branch carries those constraints in | template_info for the temploid. Yes; I think that is good. | 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". Hmm, I am lost here. Could you clarify with examples? | > | 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. the type specifier 'auto' is represented by a fresh TEMPLATE_TYPE_PARM, therefore has a TEMPLATE_TYPE_DECL. -- Gaby
