Page MenuHomePhabricator

[Concepts] Delayed Constraint Substitution
Needs ReviewPublic

Authored by saar.raz on Apr 20 2019, 5:14 PM.



Constraint expressions will now not be substituted into when instantiating constrained declarations, and all substitution will be delayed to when satisfaction or subsumption have to be determined. Also, when explicitly instantiating a class template specialization, members whose constraints are not satisfied will not be instantiated. Depends on D50360.

Diff Detail

Event Timeline

saar.raz created this revision.Apr 20 2019, 5:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2019, 5:14 PM
saar.raz updated this revision to Diff 203734.Jun 9 2019, 6:36 AM

Removed support for outdated grammar (adjusting to previous patches)

saar.raz updated this revision to Diff 204869.Jun 14 2019, 3:44 PM

Only include template parameters that occur in the atomic constraint in the parameter mapping

saar.raz updated this revision to Diff 204952.Jun 16 2019, 9:26 AM

Do not instantiate lambda expression trailing requires clause

nridge added a subscriber: nridge.Jan 21 2020, 9:31 AM
rsmith added a comment.Tue, Sep 1, 2:48 PM

I wonder if there's a cleaner way to model this:

Suppose we add a new Expr subclass for an expression with delayed template argument substitution, which would capture a list of TemplateArguments and an inner Expr* into which those template arguments have not yet been substituted. Then when we transform a trailing requires-clause, we can wrap it suitably with that expression node, and similarly when we transform a TypeConstraint we can wrap the immediately-declared constraint in the partial substitution wrapper.

We'd need to teach normalization to pick up the wrapper and turn it into a parameter mapping, and we'd need to teach satisfaction checking to actually substitute that partially-substituted wrapper, but I think the result would be a bit simpler and wouldn't need us to carefully keep track of whether each individual constraint is substituted or not. What do you think?


Please can you introduce a typedef or wrapper type for this? Maybe a struct TemplateHeadConstraints or similar?


Consider passing the union type (whatever it's called) here instead of having an Expr* argument and a TemplateParameterList* argument, at least one of which must be null.


Is it feasible to tail-allocate the pointer? (At least in the case where there is no type-constraint, it'd be nice to avoid allocating storage for it; allocating it unconditionally along with the TypeConstraint seems good enough to me.)