Functions that never return

[Alan T. Bowler [SDG]]

In article <86900032 at haddock> you write:
>
>Note: In my earlier posting I came to the tentative conclusion that the "dead
>function" concept (a function which never returns, e.g. exit) would probably
>not be sufficiently useful to be worth adding a new builtin type.  I haven't
>changed my mind; I just want to point out some possibilities.
>
There are library functions "exit", "longjmp", "abort" that never
return.  Most implementations will have quite a few more,
and using these users will normally construct a number of others.
A larger program is very likely to have several error handlers
that print a message, do some cleanup and longjmp back to
a good restart point.
   On the observation that this is a "goto" type of action
why not just recycle the "goto" keyword and allow it in function
type declarations. e.g.
    extern goto exit(int);

1) It does not require a new keyword.
2) It is compatible with the existing language
3) It is reasonably obvious what it means
4) The compiler gets the optimizing hint it needs
   without requiring a flow analysis that goes outside the
   function boundaries (i.e. you don't have to sacrifice
   separate compilation to have an optimising compiler take
   advantage of it).
5) On a similar note it gets rid of the damned 
   /*NOTREACHED*/
   by associating the property of not returning with
   the function instead of with every call to the function.