This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [c++-concepts] Check function concept definitions
- From: Andrew Sutton <andrew dot n dot sutton at gmail dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Roland Bock <rbock at eudoxos dot de>
- Date: Mon, 29 Sep 2014 11:46:03 -0400
- Subject: Re: [c++-concepts] Check function concept definitions
- Authentication-results: sourceware.org; auth=none
- References: <CANq5Syu2hUZQJU8vP4-j6TEokU_95OX2jijqY5EAxTqLM1rA+g at mail dot gmail dot com> <542975AE dot 8070701 at redhat dot com>
> Hmm, have we actually discussed this in core review? I'm not seeing it on
> the wiki. Constexpr started out this way too, and allowing static_assert
> was added pretty fast. C++11 said
>
> its function-body shall be = delete, = default, or a compound-statement that
> contains only
> â null statements,
> â static_assert-declarations
> â typedef declarations and alias-declarations that do not define classes or
> enumerations,
> â using-declarations,
> â using-directives,
> â and exactly one return statement;
>
> Is there a reason we want to be more strict than this for concept functions?
I don't remember much controversy on that particular limitation in
either Rapperswil or the previous telecon review.
The main reason for the restriction is that concept definitions are
normalized into a single constraint-expression. And it's not obvious
how things like using declarations and static-assertions should be
interpreted within the constraint language.
That said, having a static_assert inside a concept kind of defeats the
purpose since it triggers a diagnostic when its condition isn't
satisfied. That's not very SFINAE friendly :)
Maybe the restriction can relaxed when we consider the TS for adoption in 17.
Andrew