[cfe-dev] Roadmap for a Concepts implementation P0734R0, currently merged into C++20 draft

[Saar Raz via cfe-dev]

Great to hear that you're willing to get this going too :)

On Sat, Nov 18, 2017 at 3:41 AM Richard Smith <richard at metafoo.co.uk> wrote:

> the result of evaluating a concept with a set of arguments may validly
> change throughout the compilation of a program, so any notion of tracking /
> caching concept specializations might not be workable. This needs more
> analysis.
>
Can the value of a concept really change throughout the compilation of a
program? Doesn't two phase lookup and the guarantee that templates cannot
be further specialized after they've been instantiated guarantee this not
to happen? ([temp.spec]p5.3)


> * Consider how constraint normalization and subsumption checking will fit
> into the system. These are probably the two biggest pieces to design and
> implement.
>
Well yes, I see a few challenges with normalization and subsumption -
please give your input:
1. The paper introduces "conjunction" and "disjunction" as their own
'operators' that act on constraints. I guess the goal there was to avoid
people overloading operator&& and operator||. A possible implementation we
could do is take the expression as parsed, and replace BinaryOperator nodes
with either the same BinaryOperator with its arguments wrapped with casts
to bool, or create a new operator opcode and substituting that in. The
former has the problem that those bool casts weren't really written by the
user and will be confusing in diagnostics, and frankly do not conform to
the paper as they would allow 'atomic constraints' to have a type other
than bool that has a conversion to bool. The latter is probably the more
correct solution but IDK how much work introducing a new operator is gonna
be - any input on that?
2. Regarding normalization - my roadmap already incorporates caching a
'complete' version of the constraint-expression, we might as well calculate
a normalized version right there and then.
3. Normalization requires we break up ConceptSpecializationExprs into their
constituents, which would circumvent our proposed caching of concept
specializations if we were to then calculate the satisfaction of the
normalized referencing concept. How about using the non-normalized version
of the constraints to calculate the satisfaction and using the normalized
version only for subsumption checking? Can you think of any non-conformance
issues we get from this approach?
4. If we're using the normalized version for subsumption checking only, we
might as well delay the normalization to when we need to calculate
subsumption.
5. Should we or should we not cache the result of subsumptions? I tend to
think that we should, what do you thing?


> * Decouple the implementation of requires-expressions from everything
> else. I would be inclined to implement them first rather than last, but
> that's up to whoever actually does the implementation work.
>
They are decoupled except for their required support of partial-concept-ids
like so:
requires (T t) {
    { t.foo() }-> Same<bool>
}
So I'd rather implement them last after we have concept-ids.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171118/be4b3817/attachment.html>