This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]