From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,37d1760a19f7ae57
X-Google-Attributes: gid103376,public
From: dewar@schonberg.cs.nyu.edu (Robert Dewar)
Subject: Re: Q. on Automatic Package Finalization
Date: 1996/10/04
Message-ID: <dewar.844452822@schonberg>#1/1
X-Deja-AN: 187628534
references: <dewar.843919951@schonberg> <32552646.F27@watson.ibm.com>
organization: New York University
newsgroups: comp.lang.ada
Date: 1996-10-04T00:00:00+00:00
List-Id: <comp.lang.ada>


Norm Cohen says

> ">   begin
> >      ...
> >   exception
> >      ...
> >   at end
> >      < sequence of frame finalization statements >
> >   end"
>
> Interestingly, internally GNAT implements at end, but does not allow it
> to be mixed with an exception handler, and at end, unlike an exception
> handler, covers the associated declarations.

Both those differences detract from the value of "at end".


I don't think so. After all it is a trivial syntactic transformation to
go from whatever you have in mind to the semantics implemented by GNAT
(which corresponds to the standard GCC cleanup semantics).

The reason for not allowing at end and exceptions in the same scope was
simply for clarity, this makes it very clear what the semantics is whereas
if you have to allow both, then you have to answer questions like
what happens if an exception happens in the finalization?

The reason we cover the declarations is two-fold, first for almost all
internal uses of the construct (and of course it is ONLY an internal
use construct at the moment), this is more convenient, and second, as
I noted, it corresponds to the GCC cleanup notion.

But anyway, the first point I made is the critical one, you can transform
one semantics into the other trivially, so what's the issue?