On 2014-09-29 18:32, Jason Merrill wrote: > On 09/29/2014 11:46 AM, Andrew Sutton wrote: >> 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. > > A using-declaration just affects name lookup. They and > typedefs/aliases can help to make the return statement easier to write. > >> 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 :) > > True. It might still be useful if for some reason testing a concept > for a certain class of types indicates an error somewhere else. And > people are likely to try it, as indicated by the bug report. :) > >> Maybe the restriction can relaxed when we consider the TS for >> adoption in 17. > > I suppose, but I'd prefer not to wait that long. I guess we can talk > about it on the call today. > > Jason > Since I sent that sample code with the static_assert inside the concept, let me add that I wanted to test something completely different and stumbled over that internal error by accident :-)
That being said, I had expected the same rules for concepts as for constexpr functions indeed. It seemed quite natural (and would require less RAM in my brain). Best, Roland
