On 19/03/14 00:20, Steven Schveighoffer wrote:
I think we all agree that there are some things that the compiler simply cannot prove are nothrow, but to be able to write useful nothrow code, we have to paste nothrow on there anyway.
Just to clarify my understanding here: exactly how much compiler checking _is_ done of nothrow? Is it simply to confirm that whatever is called by the function contains no "throw" statements (hopefully all the way down ...), or is there more ... ?
What I'm wondering is whether just as we have @safe and @trusted for the situations where the compiler can verify and where the programmer has verified, is there a case for complementing nothrow with another attribute ("wontthrow"?) that's a programmer assurance rather than a compiler-checked guarantee?
I imagine if that was worthwhile someone would already have done it, but I'm curious.
