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

Sun Nov 19 16:39:35 PST 2017

Attached is a patch file that implements point 1 with some comments as to
what should be done next.
Changyu - you didn't answer my question - could you work on
requires-expressions and not the other parts for now?

On Sun, Nov 19, 2017 at 10:31 AM Saar Raz <saar at raz.email> wrote:

> Hi Changyu - did you submit a patch for #1?
> Anyways, it'd be great if you could work on requires expressions (25-27)
> and the diagnostic functions instead, as I already have much of the code
> figured out for the other steps and it would be a waste if you had to
> figure it out again yourself
>
> On Sun, Nov 19, 2017, 10:22 AM Changyu Li <changyu at ca.ibm.com> wrote:
>
>> Hi Saar,
>>
>> I'd like to help you implement your road map. I've finished point 1 and
>> am working on points 2 and 3. I may have some questions in the future, not
>> right now though.
>>
>>
>> ----- Original message -----
>> From: Hubert Tong <hubert.reinterpretcast at gmail.com>
>> To: Richard Smith <richard at metafoo.co.uk>
>> Cc: Saar Raz <saar at raz.email>, Changyu Li <changyu at ca.ibm.com>, Nathan
>> Wilson <nwilson20 at gmail.com>, Clang Dev <cfe-dev at lists.llvm.org>
>> Subject: Re: [cfe-dev] Roadmap for a Concepts implementation P0734R0,
>> currently merged into C++20 draft
>> Date: Fri, Nov 17, 2017 10:15 PM
>>
>>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_jtc1_sc22_wg21_docs_papers_2017_p0734r0.pdf&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_TppqN2XZ2ySkHq7c46FM6kKcTPHv0u9VoUI4-BYNJg&m=eo1IkqhJz5o151j2EqID_m9jZhqvgWxYauu4PmYltbI&s=vINFjxsX84lS2vkVxw_f7jsdy0SeFDZNFZUm8SyPsts&e=> 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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_saarraz_clang-2Dconcepts-2Droadmap&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_TppqN2XZ2ySkHq7c46FM6kKcTPHv0u9VoUI4-BYNJg&m=eo1IkqhJz5o151j2EqID_m9jZhqvgWxYauu4PmYltbI&s=H16vJSiZQS74Accey_tQE4dThQXD2gzTRZbCEPcNBuA&e=>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_TppqN2XZ2ySkHq7c46FM6kKcTPHv0u9VoUI4-BYNJg&m=eo1IkqhJz5o151j2EqID_m9jZhqvgWxYauu4PmYltbI&s=fXOz5NsHFG8dNWh4maT1eZzkDI99PUbAO9dMI3q8ntM&e=>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171120/880cc025/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stage_1_remove_existing.patch
Type: application/octet-stream
Size: 28434 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171120/880cc025/attachment.obj>