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

[Hubert Tong via cfe-dev]

Hi Saar,

As Richard mentioned, the only reason for the delay has been an issue with
finding people with available time to work on the project. I'm adding
Changyu and Nathan to the CC because they've also been active in this area.

-- HT

On Fri, Nov 17, 2017 at 8:41 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> 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/14df6933/attachment.html>