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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!alcoa.com!TUFFS1
From: TUFFS1@alcoa.com
Newsgroups: comp.lang.ada
Subject: Destroy and Unchecked Deallocation
Message-ID: <8812140455.AA16285@ajpo.sei.cmu.edu>
Date: 6 Dec 88 13:08:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

Bill Wolfe writes (Info-Ada Digest V88 #244, 23 Nov 1988):
>...
>> 
>> This needs clarification; what does a DESTROY procedure do that
>> UNCHECKED_DEALLOCATION doesn't?
>
>      Consider an ADT which contains pointers to substructures.
>      A user declares an access type pointing to an instance of your
>      ADT, and uses UNCHECKED_DEALLOCATION to destroy that instance
>      after finishing with it.  UNCHECKED_DEALLOCATION will not 
>      recursively chase down and free up what might constitute 
>      over 99% of the space occupied by the ADT.   Similarly, if your
>      ADT uses another ADT in its implememtation, your DESTROY procedure
>      will include a call to the DESTROY procedure of the sub-ADT,
>      but UNCHECKED_DEALLOCATION will remain oblivious to the method
>      which must be used to properly destroy the sub-ADT.
>...

I believe the effect you want can be implemented within Ada as it stands.  
Following LRM 13.10 (2), define a new Deallocate generic, and have the 
user avoid direct reference to Unchecked_Deallocation:

generic
  type Object is limited private;
  type Name is access Object;
  with procedure Destroy(Y: in out Object) is <>;
procedure Deallocate(X: in out Name);

with Unchecked_Deallocation;
procedure Deallocate(X: in out Name) is
  procedure Clean_Up is new Unchecked_Deallocation(Object, Name);
begin
  Destroy(X.all);
  Clean_Up(X);
end Deallocate;


Simon Tuffs
Tuffs@Alcoa.com