This is the mail archive of the
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++ - more tests
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Michael Matz <matz at suse dot de>, Matt Austern <austern at apple dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 12 Nov 2002 08:17:31 -0800
- Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests
So for me, the question isn't whether an extension might be useful
for someone, but whether it's so very useful to enough people that it
can overcome a strong bias against adding extensions. Some extensions
pass that test; I'm not yet convinced that this one does.
Yes, and I ask for specific reasons why this wouldn't pass.
I (and probably Matt) are going to argue that the burden is not on us
to provide a specific reason *not to* have an extension; the burden is
on you *to* provide a specific reason to have the extension. The
reason that I would find compelling is that there is no way to achieve
some vital piece of functionality without the extension.
Richard's recent TLS extension met that criteria to me; that gives you
a portable way of writing code that takes advantage of the TLS support
in the linker. I couldn't think of any other good way to do that, so
I didn't object.
Introducing a new control-flow construct into a language that has been
used for decades without that control-flow construct is a much more
radical change. There's no question the extension would be useful; the
question is whether it is essential.
Anyhow, I think you're beating a dead horse. :-)
Richard has agreed to try to implement and use longjmp_unwind. There's
no question that function would be useful to people in other situations,
and it doesn't require any language extension. If Richard's attempt
fails for some reason, we can reconsider.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com