Hi,
On 11/10/18 20:36, Jason Merrill wrote:
On Wed, Oct 3, 2018 at 8:18 AM Paolo Carlini <paolo.carl...@oracle.com> wrote:
a simple issue, we weren't correctly implementing 7.5.7.4 on the
terminating semicolon. Tested x86_64-linux.
If the missing semicolon is followed by }, let's allow it with a pedwarn.
I see. Unfortunately we have yet another issue in this area: our
requirement-list, as parsed in cp_parser_requirement_list, isn't the
same as requirement-seq in the working draft:
requirement-list:
requirement
requirement-list ';' requirement[opt]
vs
requirement-seq
requirement
requirement-seq requirement
thus, in particular, we accept a single requirement either terminated
with semicolon or not (which explains why we have c++/71139 and
c++/71140 es accept invalid but we don't reject anything valid). We do
this together with correctly enforcing the terminating semicolon for
simple-requirement and type-requirement and not enforcing it for
compound-requirement and nested-requirement (per the bugs at issue).
Sort of a mess. I don't know how much we care about backward
compatibility with the TS, etc, in this area (*) but it would be *so*
nice to implement requirement-seq too correctly and simply require the
terminating semicolon for all the 4 kinds of requirements...
Thanks, Paolo.
(*) In principle we could even imagine a legacy Concepts TS mode - by
and large frozen, the way of the library TR1 - and a proper C++20
concepts mode, useful for much more serious issues too. No idea if
somebody already discussed this?!?
