With respect to this:
Jason Merrill wrote:
Yes. But that's not a reason to add a slightly different non-standard
feature that would require people already using standard exception
specifications to rewrite everything. That's just a non-starter.
Maybe I missed some point: why everything should be rewritten? As far
as I understand, nothing needs to be rewritten. The programs using the
standard qualifier throw will not be aware of the new feature, and
they will compile and run as if the feature were not implemented. The
standard throw qualifier must be kept, and a new qualifier (static
throw, or _throw) would be added with the new meaning. If you like it,
you can use it by specifying -fallow_static_throws. If you don't like
it, don't use the -fallow... and your code will be standard and it
will have the standard semantics... Moreover, if you use the
-fallow_static_throws the code not using "static throw" or "_throw"
will compile and run as if the feature were not implemented...
The only bad thing here is that you have two qualifiers having
similar meanings... But I think it must be that way in order to
_avoid_ rewriting code.
However, a flag to perform static checking of standard exception specifications
and warn
about violations is very likely to be included.
The point here is that, in order to do this, you need
interprocedural analysis. If you have qualifiers as the one I
describe, you can perform the check by merely using the prototypes...
I agree with Jason that an extension which implies rewriting
everything is not very likely to be included, but it is not case. So,
what do you think now?
Cheers,
Sergio
