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

[Hubert Tong via cfe-dev]

On Tue, Nov 21, 2017 at 3:53 PM, Saar Raz <saar at raz.email> wrote:

> Agreed, I'll post a patch with fixed tests and the diagnostic removed soon.
>
> Richard - I heard from Andrew Sutton that constrained non-template
> functions had been cut out of the working draft when concepts was voted in
> because of name mangling issues - are they still left out? If so, was the
> trailing requires-clause cut out as well?
> Anyway I've noticed another problem/defect with constrained non-template
> functions as described in P0734R0, discussed here: https://groups.google.
> com/a/isocpp.org/forum/#!topic/std-discussion/CJAmcnFI86o (Andrew also
> agreed that this probably should be fixed in the way I suggested)
>
Yes, previous discussions on the issue you describe led to the same
conclusion. There are still questions over what exactly is used to
distinguish requires-clauses that are "different" without template
dependent constructs. The constraint expression really just evaluates to a
bool value, and all cases evaluating to "true" could be considered
equivalent. [basic.link]/9 in N4700 is silent to the point of being wrong
here, but I do not think we have an agreement on what the right words
should look like.


>
> On Mon, Nov 20, 2017 at 7:15 PM Hubert Tong <hubert.reinterpretcast at gmail.
> com> wrote:
>
>> On Sun, Nov 19, 2017 at 7:39 PM, Saar Raz <saar at raz.email> wrote:
>>
>>> Attached is a patch file that implements point 1 with some comments as
>>> to what should be done next.
>>>
>> Saar, I believe cfe-commits is the mailing list for patch reviews. I also
>> find Phabricator to be helpful (but it is not mandatory).
>>
>> Some comments:
>> The patch would obviously break tests, so test updates are needed. I
>> would prefer to see if some tests are salvageable by modifying them to use
>> the new syntax (and then leaving them disabled for now).
>> The error message at line 132 of the patch still refers to "concept" as a
>> specifier.
>> This particular error message is also more likely to be orphaned than not
>> depending on how the parsing is implemented.
>>
>> template <typename T>
>> inline concept C = true;
>> //     ^
>> // error: expected unqualified-id
>>
>> template <typename T>
>> concept constexpr C = true;
>> //      ^
>> // error: expected unqualified-id
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171121/bfd4c35d/attachment.html>