This is the mail archive of the 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      
CodeSourcery, LLC  

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