Hi there Frederick,

Given that noexcept is an interface promise and the risk of breakage which comes if you should ever need to remove it from a function, I'm not sure elevating it to the class level is a good idea. A tool like that should be reasonably fine-grained rather than applied to entire families of code. My opinion is that it's a good thing that you need to consider every function individually for noexcept specification; because you should reserve it only for the cases where you know with good certainty that the promise made by noexcept will never need to be broken. While your idea of having code be ill-formed if not marked noexcept is probably better than having it cause breakage more quietly, it doesn't really solve the problem of what a user is to do if they need to break that promise; and you're giving them a tool to be able to make that promise far more broadly and easily then the current status quo.

Equally, being potentially-throwing or not is a property of the function, not of the type. Your checks are still fundamentally checking whether X function may throw, not whether Y class my throw. So I'm not sure I see the motivation here to weaken that distinction. The user end will still need to check is_nothrow_move_constructible<T> or noexcept(t.some_function()) either way.

- Matthew