Re: [basic-improvements] try/finally support for c/c++ - more tests

[Matt Austern <austern@apple.com>]

On Thursday, November 7, 2002, at 06:27  PM, Mark Mitchell wrote:

>> Y'know, I don't see why people would think that.  It doesn't have
>> __except or __catch or whatever Microsoft calls it, and we say
>> explicitly that this is only for pthread_cancel() and for exceptions
>> thrown by other language runtimes...
>
> Maybe I have been so often burned by these language extensions that I
> am overly paranoid.  It's certainly possible, and Matt Austern has
> stopped commenting, so he is perhaps convinced, leaving me as a lone
> voice of insane conservatism.
>
> In contrast to Alexandre, I always thought GCC's C front end philosophy
> of having basically every feature in any language was just plain nuts.
> It's certainly lead to some major oddness over the years.

Nope.  I've been staying quiet mainly because I've agreed with what
Mark has been saying.

I have a lot less experience as a gcc maintainer than he does, but
I already have enough experience to have felt burned by language
extensions.  There have been an awful lot of cases where users
report problems with one extension or another, or worse, with some
combination of them, and I have to go through the steps of wondering:
what is this extension supposed to do?  was this particular corner
case ever considered?  what does the documentation say, and it is
right?  has this extension gone stale?  This sort of confusion is a
burden for users and implementors.

Partly the reason I lean toward conservatism is my experience on
standards bodies.  (I know I'm not the only person on this
list with such experience.)  I've learned that language design is
hard.  I've learned also that adding a major new language feature,
and specifying it adequately, is always harder than it looks.  It's
rarely good enough to give a short writeup describing the feature:
what's more common is pervasive changes throughout the specification,
as you describe, one by one, how this feature interacts with what's
already there.  Especially hard for us, since we've got so many
extensions already.  Language extensions are sometimes necessary, but
there should be a high standard of proof.

Finally, I'm concerned about the idea of putting in a language
extension just to meet the needs of a single project.  That's the
way to get language evolution without direction.

One compromise suggestion I've seen that might be reasonable, if the
glibc/pthreads argument is considered compelling: give the primitives
ugly names, warn users against putting them in their own code (and
by "warn" I mean both a note in the documentation and a compiler
warning), and use them solely as primitives for glibc implementation.
That way we give ourselves more freedom to change or remove them in
the future if appropriate.

I'm still not 100% sure I understand the glibc/pthreads discussion,
though.  There was some speculation that, with this change, all users
who want to use pthread cancelation in their code will have to 
explicitly
add -fexceptions to their command lines.  What was the outcome of that
discussion?  If there was an outcome, I missed it.

			--Matt