Version 1.4 of 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 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)); --
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