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

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Fri Nov 17 17:41:04 PST 2017


On 17 November 2017 at 16:24, Saar Raz via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> Hi all,
>
> As I've read and seen in Clang's code, a Concepts implementation in Clang
> hasn't really been pushed forward in the past year, with only very, very
> little code in place right now regarding Concepts, placed by Hubert Tong,
> CC'd, back in February, and very little to non-existent discussions in the
> mailing lists.
>
> As of the Toronto meeting back in July, a subset of the original Concepts
> TS was merged into draft C++20, which omits some shorthand notations for
> concepts but keeps the core parts of the language feature. Most notably -
> function concepts were removed, as well as the 'bool' keyword after the
> 'concept' keyword, and the 'introducer' and "terse/natural syntax" were
> omitted.
>
> I believe we should *go ahead and implement P0734R0 now *for the
> following reasons:
>  - P0734R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0734r0.pdf> hasn't
> yet been implemented in any compiler (excluding GCC which implements a
> different proposal), and furthermore *no Concepts implementation was made
> from specification* - Andrew Sutton who worked on the GCC implementation
> also wrote the proposal. Doing a concepts implementation now would, I
> believe, help the committee discover defects and in general be more
> confident in the proposal.
> - to be honest, it is* really not that hard *to implement, and can, I
> believe, be done in a month or two.
> - Concepts will be present in C++2a unless something extraordinary happens
> - if not in their current form, then in a very similar form with maybe a
> few more terse syntaxes introduced* which would not break existing code*
> but just allow for nicer code - in any case, I believe it is a good time to
> lay a foundation for the core of the language feature which seems pretty
> stable already and were agreed upon by the committee.
>
> I took a look at the relevant code and the proposal and hereby propose* a
> roadmap for implementing *Concepts in clang as it stands today:
> https://github.com/saarraz/clang-concepts-roadmap
> I broke it up into commit-sized chunks, which should take us to a working
> implementation of the proposal. I'm of course willing to implement all of
> this if needed.
>

Thank you for your analysis and the offer to help out!

We are very much open to adding support for P0734R0 to Clang, along with
all other features voted into the working draft for C++20. The only reason
this has not already been implemented is a lack of volunteers such as
yourself with the time to devote to the task.

Your roadmap looks to be in good shape. I have a few suggestions:

* For point 4, consider modeling an id-expression that names a concept
specialization as a DeclRefExpr rather than introducing a new AST node.
That's our general way of representing "an expression denoting a name
associated with some declaration by name lookup", and is currently used for
things like variables, functions and enumerators. This will likely be
significantly simpler if you do in fact make a ConceptSpecialization be a
declaration. (You'll need a templated declaration to live within the
ConceptTemplateDecl anyway, if you're going to follow the usual AST model
where a template declaration is a wrapper around some other declaration.)
However, there may be a reason why this is infeasible -- particularly, 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.

* Consider how constraint normalization and subsumption checking will fit
into the system. These are probably the two biggest pieces to design and
implement.

* 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.


> Please tell me what you think and post issues/pull requests to the roadmap
> repo or post here.
> I'd really like to see this get going.
>
> Thanks!
> Saar
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171117/08e9d599/attachment-0001.html>


More information about the cfe-dev mailing list