Version 1.5 of ai05s/ai05-0152-1.txt

Unformatted version of ai05s/ai05-0152-1.txt version 1.5
Other versions for file ai05s/ai05-0152-1.txt

!standard H.4(8/1)          09-10-12 AI05-0152-1/03
!class Amendment 09-05-23
!status Amendment 201Z 09-06-25
!status WG9 Approved 09-11-05
!status ARG Approved 6-0-0 09-06-14
!status work item 09-05-23
!status received 09-05-23
!priority Medium
!difficulty Medium
!subject Restriction No_Anonymous_Allocators
!summary
Add restriction_identifier No_Anonymous_Allocators.
!problem
Allocators for anonymous access types have various special properties that make them very different than allocators for named access types:
(1) Allocators for anonymous access parameters are supposed to allocate the object from a pool "created at the point of the allocator"; the object has the innermost master surrounding the allocator as the anonymous access type is created at the point of each call, and thus the object is finalized right after the call (13.11(25.2/2), 6.4.1(9), 7.6.1(11/2)).
(2) Allocators for anonymous access discriminants cause "coextensions", with their own set of rules and implementation overhead.
(3) Allocators for other kinds of anonymous access types create objects with the accessibility of the point of the access_definition. This means that there is little control over the accessibility of the allocated object. The storage pool used "need not support" deallocation (13.11(25.3/2)).
In addition, for all kinds of anonymous access types, the use of specified (user-defined) storage pools is not possible. Nor is the use of Unchecked_Deallocation supported.
These properties make using anonymous access types as a complete replacement for named access types impossible. For that sort of use, it is better to use a named access type (for which control over the storage pool, object lifetime, and deallocation is possible) to do allocation, then convert to anonymous access types as needed. If this model is being followed, directly allocating an object of an anonymous access type is a mistake.
!proposal
(See wording.)
!wording
Add after H.4(8/1):
No_Anonymous_Allocators Allocators of anonymous access types are not allowed.
!discussion
Anomymous access types cannot be passed as generic formal types, so we don't have to worry about generic cases here.
!example
pragma Restrictions (No_Anonymous_Allocators);
package P is
procedure Proc (X : access Integer);
end P;
with P; procedure Test is begin P.Proc (new Integer'(10)); -- Illegal. end Test;
!corrigendum H.4(8/1)
Insert after the paragraph:
No_Local_Allocators
Allocators are prohibited in subprograms, generic subprograms, tasks, and entry bodies.
the new paragraph:
No_Anonymous_Allocators
Allocators of anonymous access types are not allowed.
!ACATS test
Add an ACATS test for this new feature.
!appendix

This AI was split from AI05-0138-1; there is a small amount of discussion
on this idea in the volumous e-mail in that AI.

****************************************************************



Questions? Ask the ACAA Technical Agent