CVS difference for ais/ai-00230.txt
--- ais/ai-00230.txt 2003/09/27 23:27:17 1.11
+++ ais/ai-00230.txt 2003/10/29 22:54:09 1.12
@@ -1,5 +1,24 @@
-!standard 3.10 (01) 03-09-27 AI95-00230/07
+!standard 03.04.01(06) 03-10-22 AI95-00230/08
+!standard 03.06(07)
+!standard 03.06(22/1)
+!standard 03.07(10)
+!standard 03.08(18/1)
+!standard 03.10(12)
+!standard 03.10(17)
+!standard 03.10.2(12)
+!standard 04.02(02)
+!standard 04.02(08)
+!standard 04.05.02(07)
+!standard 04.05.02(09)
+!standard 04.06(13)
+!standard 04.06(18)
+!standard 08.05.01(02)
+!standard 08.05.01(03)
+!standard 08.05.01(06)
+!standard 13.11(25)
!class amendment 00-04-13
+!status work item 00-10-27
+!status ARG Approved 10-0-0 03-10-03
!status work item 00-04-13
!status received 00-04-13
!priority Medium
@@ -173,16 +192,12 @@
subtype_indication{,} or discrete_subtype_definition is elaborated.
...
-Change 3.10(12) and 3.10(17) to list all places where access_definition
-occurs, or none of them.
+Change 3.10(12) and 3.10(17) to eliminate the list of places where
+access_definition occurs. (In both cases, this text is not required,
+and listing four places (access discriminant, access parameter,
+component_definition, and object_renaming_declaration) is awkward. Besides,
+we don't use text to list where subtype_indication [for instance] is allowed.)
-Change paragraph 3.10(13) as follows:
-
- For each [(named)] access type, there is [a literal NULL which has] a null
- access value designating no entity at all. The null value of [a named] {an}
- access type is the ... in the case of [a named] {an} access-to-object type,
- an allocator, which returns ...
-
Add the following paragraph before 3.10.2(12):
The accessibility level of the anonymous access type defined by an
@@ -198,7 +213,7 @@
of the access type is the same as the level of the containing
composite type.}
-Delete paragraphs 4.2(2) and 4.2(7). [The latter change presumes AI-231.]
+Delete paragraph 4.2(2).
Change paragraph 4.2(8) as follows:
... is of type universal_real. {The literal NULL is of type
@@ -237,8 +252,6 @@
shall be {universal_access or} an access-to-subprogram type. Further{, if
not universal_access}:
-Delete paragraph 4.6(49). [This change presumes AI-231]
-
Change paragraph 8.5.1(2) as follows:
object_renaming_declaration ::=
@@ -252,29 +265,32 @@
access_definition, to an anonymous access type whose designated type
is the same as that of the access_definition}.
-[NOTE: If AI-231 is adopted, then 8.5.1(4) should probably include a
+[NOTE: If AI-231 is adopted, then 8.5.1(4) should include a
legality rule that requires the access_definition to be
access-to-constant if and only if the renamed object is
-access-to-constant. Alternatively, we could allow the
-access-to-constantness to be carried over from the renamed object in the
-same way that constantness is. I prefer requiring explicit
-"access constant" rather than carrying over acc-to-const-ness.]
+access-to-constant. This is type-specific information, which is
+included in a renames declaration.]
Change paragraph 8.5.1(6) as follows:
... any constraint implied by the subtype_mark {or access_definition}
of the object_renaming_declaration is ignored.
+
+Replace paragraph 13.11(25) by:
-Change paragraph 13.11(25) as follows:
+ The storage pool used for an allocator of an anonymous
+ access type should be determined as follows:
- {If the designated type of the type of an allocator is limited, then the
- storage pool used for the allocator should also be used for any allocators
- initializing access discriminants of the designated object, or of its
- limited subcomponents. In other cases, the storage pool for an allocator of}
- [A storage pool for] an anonymous access type should be created at the point
- of {the allocator} [an allocator for the type], and be reclaimed when the
- designated object becomes inaccessible.
+ * If the allocator is initializing an access discriminant of an object
+ of a limited type, and the discriminant is itself a subcomponent of an
+ object being created by an outer allocator, then the storage pool used
+ for the outer allocator should also be used for the allocator initializing the
+ access discriminant;
+ * Otherwise, the storage pool should be created at the point of the allocator,
+ and be reclaimed when the allocated object becomes inaccessible.
+
+
!example
package P is
@@ -411,6 +427,284 @@
ways, and in particular you couldn't safely convert to T'Access
from some potentially local access type.
+d) Implementations which materialize all implicit types would have problems,
+as there is no limit to the types that could be constructed (T'Access'Access,
+T'Access'Access'Access, etc.)
+
+!corrigendum 3.4.1(6)
+
+@drepl
+@xhang<@xterm<Universal types>
+Universal types are defined for (and belong to) the integer, real, and fixed
+point classes, and are referred to in this standard as respectively,
+@i<universal_integer>, @i<universal_real>, and @i<universal_fixed>. These are
+analogous to class-wide types for these language-defined numeric classes. As
+with class-wide types, if a formal parameter is of a universal type, then an
+actual parameter of any type in the corresponding class is acceptable. In
+addition, a value of a universal type (including an integer or real
+@fa<numeric_literal>) is ``universal'' in that it is acceptable where some
+particular type in the class is expected (see 8.6).>
+@dby
+@xhang<@xterm<Universal types>
+Universal types are defined for (and belong to) the integer, real, fixed, and
+access point classes, and are referred to in this standard as respectively,
+@i<universal_integer>, @i<universal_real>, @i<universal_fixed>, and
+@i<universal_access>. These are analogous to class-wide types for these
+language-defined classes. As with class-wide types, if a formal parameter is of
+a universal type, then an actual parameter of any type in the corresponding
+class is acceptable. In addition, a value of a universal type (including an
+integer or real @fa<numeric_literal>) is ``universal'' in that it is acceptable
+where some particular type in the class is expected (see 8.6).>
+
+!corrigendum 3.6(7)
+
+@drepl
+@xcode<@fa<component_definition ::= [>@ft<@b<aliased>>@fa<] subtype_indication>>
+@dby
+@xcode<@fa<component_definition ::= [>@ft<@b<aliased>>@fa<] subtype_indication | access_definition>>
+
+!corrigendum 3.6(22/1)
+
+@drepl
+The elaboration of a @fa<discrete_subtype_definition> that does not contain
+any per-object expressions creates the discrete
+subtype, and consists of the elaboration of the @fa<subtype_indication> or the
+evaluation of the @fa<range>. The elaboration of a
+@fa<discrete_subtype_definition> that contains one or more per-object
+expressions is defined in 3.8. The elaboration of a @fa<component_definition>
+in an @fa<array_type_definition> consists of the elaboration of the
+@fa<subtype_indication>. The elaboration of any
+@fa<discrete_subtype_definition>s and the elaboration of
+the @fa<component_definition> are performed in an arbitrary order.
+@dby
+The elaboration of a @fa<discrete_subtype_definition> that does not contain
+any per-object expressions creates the discrete
+subtype, and consists of the elaboration of the @fa<subtype_indication> or the
+evaluation of the @fa<range>. The elaboration of a
+@fa<discrete_subtype_definition> that contains one or more per-object
+expressions is defined in 3.8. The elaboration of a @fa<component_definition>
+in an @fa<array_type_definition> consists of the elaboration of the
+@fa<subtype_indication> or @fa<access_definition>. The elaboration of any
+@fa<discrete_subtype_definition>s and the elaboration of
+the @fa<component_definition> are performed in an arbitrary order.
+
+!corrigendum 3.7(10)
+
+@ddel
+A @fa<discriminant_specification> for an access discriminant shall appear only
+in the declaration for a task or protected type, or for a type with the
+reserved word @b<limited> in its (full) definition or in that of one of its
+ancestors. In addition to the places where Legality Rules normally apply (see
+12.3), this rule applies also in the private part of an instance of a generic
+unit.
+
+!corrigendum 3.8(18/1)
+
+@drepl
+Within the definition of a composite type, if a @fa<component_definition> or
+@fa<discrete_subtype_definition> (see 9.5.2) includes a @fa<name> that denotes
+a discriminant of the type, or that is an @fa<attribute_reference> whose
+@fa<prefix> denotes the current instance of the type, the expression containing the
+@fa<name> is called a @i<per-object expression>, and the @fa<constraint> or
+@fa<range> being defined is called a @i<per-object constraint>. For the
+elaboration of a @fa<component_definition> of a @fa<component_declaration> or
+the @fa<discrete_subtype_definition> of an @fa<entry_declaration> for an entry
+family (see 9.5.2), if the @fa<constraint> or @fa<range> of the
+@fa<subtype_indication> or @fa<discrete_subtype_definition> is not a per-object
+constraint, then the @fa<subtype_indication> or @fa<discrete_subtype_definition>
+is elaborated. On the other hand, if the @fa<constraint> or @fa<range> is a
+per-object constraint, then the elaboration consists of the evaluation of any
+included expression that is not part of a per-object expression. Each such
+expression is evaluated once unless it is part of a named association in a
+discriminant constraint, in which case it is evaluated once for each associated
+discriminant.
+@dby
+Within the definition of a composite type, if a @fa<component_definition> or
+@fa<discrete_subtype_definition> (see 9.5.2) includes a @fa<name> that denotes
+a discriminant of the type, or that is an @fa<attribute_reference> whose
+@fa<prefix> denotes the current instance of the type, the expression containing the
+@fa<name> is called a @i<per-object expression>, and the @fa<constraint> or
+@fa<range> being defined is called a @i<per-object constraint>. For the
+elaboration of a @fa<component_definition> of a @fa<component_declaration> or
+the @fa<discrete_subtype_definition> of an @fa<entry_declaration> for an entry
+family (see 9.5.2), if the component subtype is defined by an
+@fa<access_definition> or if the @fa<constraint> or @fa<range> of the
+@fa<subtype_indication> or @fa<discrete_subtype_definition> is not a per-object
+constraint, then the @fa<access_definition>, @fa<subtype_indication>, or
+@fa<discrete_subtype_definition> is elaborated. On the other hand, if the
+@fa<constraint> or @fa<range> is a per-object constraint, then the elaboration
+consists of the evaluation of any included expression that is not part of a
+per-object expression. Each such expression is evaluated once unless it is part
+of a named association in a discriminant constraint, in which case it is
+evaluated once for each associated discriminant.
+
+!corrigendum 3.10(12)
+
+@drepl
+An @fa<access_definition> defines an anonymous general access-to-variable type;
+the @fa<subtype_mark> denotes its @i<designated subtype>. An
+@fa<access_definition> is used in the specification of an access discriminant
+(see 3.7) or an access parameter (see 6.1).
+@dby
+An @fa<access_definition> defines an anonymous general access-to-variable type;
+the @fa<subtype_mark> denotes its @i<designated subtype>.
+
+!corrigendum 3.10(17)
+
+@drepl
+The elaboration of an access_definition creates an anonymous general
+access-to-variable type [(this happens as part of the initialization of an
+access parameter or access discriminant)].
+@dby
+The elaboration of an access_definition creates an anonymous general
+access-to-variable type.
+
+!corrigendum 3.10.2(12)
+
+@drepl
+@xbullet<The accessibility level of the anonymous access type of an access
+discriminant is the same as that of the containing object or associated
+constrained subtype.>
+@dby
+@xbullet<The accessibility level of the anonymous access type defined by an
+@fa<access_definition> of an @fa<object_renaming_declaration> is the same as
+that of the renamed object (view).>
+@xbullet<The accessibility level of the anonymous access type of an access
+discriminant specified for a limited type is the same as the
+containing object or associated constrained subtype. For other
+components having an anonymous access type, the accessibility level
+of the access type is the same as the level of the containing
+composite type.>
+
+!corrigendum 4.2(2)
+
+@ddel
+The expected type for a literal @b<null> shall be a single access type.
+
+!corrigendum 4.2(8)
+
+@drepl
+An integer literal is of type @i<universal_integer>. A real literal is of type
+@i<universal_real>.
+@dby
+An integer literal is of type @i<universal_integer>. A real literal is of type
+@i<universal_real>. The literal @b<null> is of type @i<universal_access>.
+
+!corrigendum 4.5.2(7)
+
+@dinsa
+@xcode<@b<function> "=" (Left, Right : T) @b<return> Boolean
+@b<function> "/="(Left, Right : T) @b<return> Boolean>
+@dinss
+The following additional equality operators for the @i<universal_access> type
+are declared in package Standard for use with anonymous access types:
+
+@xcode<@b<function> "=" (Left, Right : @i<universal_access>) @b<return> Boolean
+@b<function> "/="(Left, Right : @i<universal_access>) @b<return> Boolean>
+
+!corrigendum 4.5.2(9)
+
+@dinsa
+@xcode<@b<function> "<" (Left, Right : T) @b<return> Boolean
+@b<function> "<="(Left, Right : T) @b<return> Boolean
+@b<function> "@>" (Left, Right : T) @b<return> Boolean
+@b<function> "@>="(Left, Right : T) @b<return> Boolean>
+@dinss
+@i<@s8<Name Resolution Rules>>
+
+At least one of the operands of the equality operators for @i<universal_access>
+shall be of an anonymous access type.
+
+@i<@s8<Legality Rules>>
+
+The operands of the equality operators for @i<universal_access> shall be
+convertible to one another (see 4.6).
+
+!corrigendum 4.6(13)
+
+@drepl
+If the target type is a general access type, then the operand type shall be an
+access-to-object type. Further:
+@dby
+If the target type is @i<universal_access>, then the operand type shall be an
+access type.
+
+If the target type is a general access-to-object type, then
+the operand shall be @i<universal_access> or an access-to-object type.
+Further, if not @i<universal_access>:
+
+!corrigendum 4.6(18)
+
+@drepl
+If the target type is an access-to-subprogram type, then the operand type
+shall be an access-to-subprogram type. Further:
+@dby
+If the target type is an access-to-subprogram type, then the operand type
+shall be @i<universal_access> or an access-to-subprogram type. Further, if
+not @i<universal_access>:
+
+!corrigendum 8.5.1(2)
+
+@drepl
+@xcode<@fa<object_renaming_declaration ::=
+ defining_identifier : subtype_mark >@ft<@b<renames>>@fa< object_name;>>
+@dby
+@xcode<@fa<object_renaming_declaration ::=
+ defining_identifier : subtype_mark >@ft<@b<renames>>@fa< object_name;
+ | defining_identifier : access_definition >@ft<@b<renames>>@fa< object_name;>>
+
+!corrigendum 8.5.1(3)
+
+@drepl
+The type of the @fa<object_name> shall resolve to the type determined by the
+@fa<subtype_mark>.
+@dby
+The type of the @fa<object_name> shall resolve to the type determined by
+the @fa<subtype_mark>, or in the case where the type is defined by an
+@fa<access_definition>, to an anonymous access type whose designated type
+is the same as that of the @fa<access_definition>.
+
+!corrigendum 8.5.1(6)
+
+@drepl
+An @fa<object_renaming_declaration> declares a new view of the renamed object
+whose properties are identical to those of the renamed view. Thus, the
+properties of the renamed object are not affected by the
+@fa<renaming_declaration>. In particular, its value and whether or not it is a
+constant are unaffected; similarly, the constraints that apply to an object are
+not affected by renaming (any constraint implied by the @fa<subtype_mark> of
+the @fa<object_renaming_declaration> is ignored).
+@dby
+An @fa<object_renaming_declaration> declares a new view of the renamed object
+whose properties are identical to those of the renamed view. Thus, the
+properties of the renamed object are not affected by the
+@fa<renaming_declaration>. In particular, its value and whether or not it is a
+constant are unaffected; similarly, the constraints that apply to an object are
+not affected by renaming (any constraint implied by the @fa<subtype_mark> or
+@fa<access_definition> of the @fa<object_renaming_declaration> is ignored).
+
+!corrigendum 13.11(25)
+
+@drepl
+A storage pool for an anonymous access type should be created at the point of
+an allocator for the type, and be reclaimed when the designated object becomes
+inaccessible.
+@dby
+The storage pool used for an @fa<allocator> of an anonymous access type should
+be determined as follows:
+@xbullet<If the @fa<allocator> is initializing an access discriminant of an
+object of a limited type, and the discriminant is itself a subcomponent of an
+object being created by an outer @fa<allocator>, then the storage pool used
+for the outer @fa<allocator> should also be used for the @fa<allocator>
+initializing the access discriminant;>
+@xbullet<Otherwise, the storage pool should be created at the point of the
+@fa<allocator>, and be reclaimed when the allocated object becomes
+inaccessible.
+
+!ACATS test
+
+Tests should be created to check on the implementation of this feature.
+
!appendix
Randy Brukardt 00-04-13
@@ -1883,6 +2177,16 @@
control over nullness, and constantness of the designated object.
[See AI body for current proposal - Ed.]
+
+*************************************************************
+
+Editor's notes, October 22, 2003
+
+In creating !corrigendum sections for this AI, I noticed that several wording
+changes are needed only if AI-231 is approved. I moved these wording changes
+to that AI. AI-231 should be written to presume that AI-230 is approved (as it
+is ahead of AI-231 in the ARG process); in particular, the needed change to
+8.5.1(4) should be included in AI-231.
*************************************************************
Questions? Ask the ACAA Technical Agent