> 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
