On Thu, Oct 11, 2018 at 4:31 PM Paolo Carlini <paolo.carl...@oracle.com> wrote: > > 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...
And allowing a missing semicolon at the end of the list/sequence (with a pedwarn) smooths over the difference. > (*) 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?!? That seems like a lot of hassle for little use; we can't just put it in a different file like the library can, and users of concepts will want to the up-to-date implementation. If someone wants to compare against the current TS implementation, they can use GCC 8. BTW, I would discourage you from messing much with the concepts code at this point, as a major overhaul should be coming soon. Jason
