CVS difference for ais/ai-00231.txt

Differences between 1.12 and version 1.13
Log of other versions for file ais/ai-00231.txt

--- ais/ai-00231.txt	2004/01/08 04:16:38	1.12
+++ ais/ai-00231.txt	2004/01/23 04:59:24	1.13
@@ -1,8 +1,27 @@
-!standard  3.10      (06)                        03-12-11  AI95-00231/07
+!standard  3.10      (06)                        04-01-10  AI95-00231/08
+!standard  3.2.3     (03)
+!standard  3.2.3     (05)
+!standard  3.7       (05)
+!standard  3.7       (09)
+!standard  3.10      (02)
 !standard  3.10      (12)
+!standard  3.10      (13)
+!standard  3.10      (14/1)
+!standard  3.10      (15)
+!standard  4.2       (07)
 !standard  4.6       (49)
+!standard  4.6       (51)
+!standard  4.9.1     (02)
+!standard  6.1       (15)
+!standard  6.1       (23)
+!standard  6.1       (24)
+!standard  8.5.1     (04)
 !standard  8.6       (25)
+!standard  12.5.1    (10)
+!standard  12.5.4    (04)
 !class amendment 00-04-13
+!status Amendment 200Y 04-01-09
+!status ARG Approved 10-0-1  03-12-13
 !status work item 00-04-13
 !status received 00-04-13
 !priority Medium
@@ -52,8 +71,11 @@
 
     The subtype of a discriminant may be defined by {an optional null_exclusion and} a
     subtype_mark, in which case the subtype_mark shall denote a discrete or access
-    subtype, ...
+    subtype, .... is of an anonymous [general access-to-variable]
+    {access} type [whose designated subtype is denoted by the subtype_mark
+    of the access_definition].
 
+
 Modify 3.10(2) to:
 
     access_type_definition ::=
@@ -77,8 +99,12 @@
     access_definition defines an access subtype which excludes the null value;
     otherwise the subtype includes a null value. An access_definition is used
     in the specification of an access discriminant (see 3.7) or an access
-    parameter (see 6.1). [NOTE: Drop this last sentence or make it cover all
-    uses of access_definition if AI-230 is approved.]
+    parameter (see 6.1). [NOTE: Drop this last sentence if AI-230 is approved.]
+
+   AARM Note: Controlling access_definitions are null-excluding because it
+   it necessary to read the tag to dispatch, and @b<null> has no tag. We
+   would have preferred to require @b<not null> to be specified for such
+   parameters, but that would have been too incompatible with Ada 95.
 
 Modify 3.10(13) as follows:
    For each [(named)] access type, there is [a literal NULL which has] a null
@@ -132,14 +158,20 @@
     {determined} by the {optional null_exclusion and the} subtype_mark, or
     defined by the access_definition, in the parameter_specification.
 
-Modify 8.5.1(4) to 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. This is only needed if AI-230 is approved.
-
-Modify 8.6(25) so that implicit conversion to any anonymous access type is
-permitted, with the expected rules (i.e. it is illegal to convert an
-access-to-constant to access-to-variable).
+Modify 6.1(24):
+    .... An access parameter is of an anonymous [general access-to-variable]
+    {access} type (see 3.10). ...
+
+Add to the end of 8.5.1(4), if AI-230 is adopted:
+    In the case where the type is defined by an access_definition,
+    the renamed entity shall be of an access-to-constant type if and
+    only if the access_definition defines an access-to-constant type.
+
+Modify 8.6(25):
+  * when T is an anonymous access{-to-object} type (see 3.10) with designated
+    type D, to an access-to-[variable]{object} type whose designated type is
+    D'Class or is covered by D{, and that is access-to-constant only if T is
+    access-to-constant}.
 
 Add after 12.5.1(10)
 
@@ -232,6 +264,263 @@
 internally obeying null exclusion would make it that much harder to
 reuse the generic.
 
+
+[Note: In the !corrigendum wording below, we assume that AI-230 is also
+approved.]
+
+!corrigendum 3.2.2(3)
+
+@drepl
+@xcode<@fa<subtype_indication ::=  subtype_mark [constraint]>>
+@dby
+@xcode<@fa<subtype_indication ::=
+   [null_exclusion] subtype_mark [scalar_constraint | composite_constraint]>>
+
+!corrigendum 3.2.2(5)
+
+@ddel
+@xcode<@fa<constraint ::= scalar_constraint | composite_constraint>>
+
+!corrigendum 3.7(5)
+
+@drepl
+@xcode<@fa<discriminant_specification ::=
+    defining_identifier_list : subtype_mark [:= default_expression]
+  | defining_identifier_list : access_definition [:= default_expression]>>
+@dby
+@xcode<@fa<discriminant_specification ::=
+    defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression]
+  | defining_identifier_list : access_definition [:= default_expression]>>
+
+!corrigendum 3.7(9)
+
+@drepl
+The subtype of a discriminant may be defined by a @fa<subtype_mark>, in which
+case the @fa<subtype_mark> shall denote a discrete or access subtype, or it may
+be defined by an @fa<access_definition> (in which case the @fa<subtype_mark> of
+the @fa<access_definition> may denote any kind of subtype). A discriminant that
+is defined by an @fa<access_definition> is called an @i<access discriminant> and is
+of an anonymous general access-to-variable type whose designated subtype is
+denoted by the @fa<subtype_mark> of the @fa<access_definition>.
+@dby
+The subtype of a discriminant may be defined by an optional @fa<null_exclusion>
+and a @fa<subtype_mark>, in which case the @fa<subtype_mark> shall denote a
+discrete or access subtype, or it may be defined by an @fa<access_definition>
+(in which case the @fa<subtype_mark> of the @fa<access_definition> may denote
+any kind of subtype). A discriminant that is defined by an
+@fa<access_definition> is called an @i<access discriminant> and is of an
+anonymous access type.
+
+!corrigendum 3.10(2)
+
+@drepl
+@xcode<@fa<access_type_definition ::=
+    access_to_object_definition
+  | access_to_subprogram_definition>>
+@dby
+@xcode<@fa<access_type_definition ::=
+    [null_exclusion] access_to_object_definition
+  | [null_exclusion] access_to_subprogram_definition>>
+
+!corrigendum 3.10(6)
+
+@drepl
+@xcode<@fa<access_definition ::= >@ft<@b<access>>@fa< subtype_mark>>
+@dby
+@xcode<@fa<null_exclusion ::= >@ft<@b<not null>>
+@fa<access_definition ::=
+   [null_exclusion] >@ft<@b<access>>@fa< [general_access_modifier] subtype_mark>>
+
+!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 type; the
+@fa<subtype_mark> denotes its @i<designated subtype>. If the reserved word
+@b<constant> appears, the type is an access-to-constant type; otherwise it is
+an access-to-variable type. If a @fa<null_exclusion> is present, or the
+@fa<access_definition> is for a controlling access parameter (see 3.9.2), the
+@fa<access_definition> defines an access subtype which excludes the null value;
+otherwise the subtype includes a null value.
+
+!corrigendum 3.10(13)
+
+@drepl
+For each (named) access type, there is a literal @b<null> which has a null access
+value designating no entity at all. The null value of a named access type is
+the default initial value of the type. Other values of an access type are
+obtained by evaluating an @fa<attribute_reference> for the Access or
+Unchecked_Access attribute of an aliased view of an object or non-intrinsic
+subprogram, or, in the case of a named access-to-object type, an @fa<allocator>,
+which returns an access value designating a newly created object (see 3.10.2).
+@dby
+For each access type, there is a null access value designating no entity at
+all. The null value of an access type is the default initial value of the type.
+Other values of an access type are obtained by evaluating an
+@fa<attribute_reference> for the Access or Unchecked_Access attribute of an
+aliased view of an object or non-intrinsic subprogram, or, in the case of an
+access-to-object type, an @fa<allocator>, which returns an access value
+designating a newly created object (see 3.10.2).
+
+!corrigendum 3.10(14/1)
+
+@drepl
+All subtypes of an access-to-subprogram type are constrained. The first subtype
+of a type defined by an @fa<access_definition> or an
+@fa<access_to_object_definition> is unconstrained if the designated subtype is
+an unconstrained array or discriminated subtype; otherwise it is constrained.
+@dby
+All subtypes of an access-to-subprogram type are constrained. The first subtype
+of a type defined by an @fa<access_definition> or an
+@fa<access_to_object_definition> is unconstrained if the designated subtype is
+an unconstrained array or discriminated subtype; otherwise it is constrained.
+The first subtype of a type defined by an access_type_definition excludes the
+null value if a @fa<null_exclusion> is present; otherwise, the first subtype
+includes the null value.
+
+!corrigendum 3.10(15)
+
+@drepl
+A @fa<composite_constraint> is @i<compatible> with an unconstrained access
+subtype if it is compatible with the designated subtype. An access value
+@i<satisfies> a @fa<composite_constraint> of an access subtype if it equals the
+null value of its type or if it designates an object whose value satisfies the
+constraint.
+@dby
+A @fa<composite_constraint> is @i<compatible> with an unconstrained access
+subtype if it is compatible with the designated subtype. A @fa<null_exclusion>
+is compatible with an access subtype if the subtype includes a null value. An
+access value @i<satisfies> a @fa<composite_constraint> of an access subtype if
+it equals the null value of its type or if it designates an object whose value
+satisfies the constraint. An access value satisifes a @fa<null_exclusion>
+imposed on an access subtype if it does not equal the null value of its type.
+
+!corrigendum 4.2(7)
+
+@ddel
+A literal @fa<null> shall not be of an anonymous access type, since such types
+do not have a null value (see 3.10).
+
+!corrigendum 4.6(49)
+
+@drepl
+@xinbull<If the target type is an anonymous access type, a check is made that
+the value of the operand is not null; if the target is not an anonymous access
+type, then the result is null if the operand value is null.>
+@dby
+@xinbull<If the operand value is null, the result of the conversion is the null
+value of the target type.>
+
+!corrigendum 4.6(51)
+
+@drepl
+After conversion of the value to the target type, if the target subtype is
+constrained, a check is performed that the value satisfies this constraint.
+@dby
+After conversion of the value to the target type, if the target subtype is
+constrained, a check is performed that the value satisfies this constraint.
+If the target subtype excludes the null value, then a check is made that
+the value is not null.
+
+!corrigendum 4.9.1(2)
+
+@drepl
+A subtype @i<statically matches> another subtype of the same type if they have
+statically matching constraints. Two anonymous access subtypes statically match
+if their designated subtypes statically match.
+@dby
+A subtype @i<statically matches> another subtype of the same type if they have
+statically matching constraints, and, for access subtypes, either both or
+neither exclude null. Two anonymous access-to-object subtypes statically match
+if their designated subtypes statically match, and either both or neither
+exclude null, and either both or neither are access-to-constant.
+
+!corrigendum 6.1(15)
+
+@drepl
+@xcode<@fa<parameter_specification ::=
+    defining_identifier_list : mode subtype_mark [:= default_expression]
+  | defining_identifier_list : access_definition [:= default_expression]>>
+@dby
+@xcode<@fa<parameter_specification ::=
+    defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]
+  | defining_identifier_list : access_definition [:= default_expression]>>
+
+!corrigendum 6.1(23)
+
+@drepl
+The nominal subtype of a formal parameter is the subtype denoted by the
+@fa<subtype_mark>, or defined by the @fa<access_definition>, in the
+@fa<parameter_specification>.
+@dby
+The nominal subtype of a formal parameter is the subtype determined
+by the optional @fa<null_exclusion> and the subtype_mark, or
+defined by the @fa<access_definition>, in the @fa<parameter_specification>.
+
+!corrigendum 6.1(24)
+
+@drepl
+An @i<access parameter> is a formal @b<in> parameter specified by an
+@fa<access_definition>. An access parameter is of an anonymous general
+access-to-variable type (see 3.10). Access parameters allow dispatching calls
+to be controlled by access values.
+@dby
+An @i<access parameter> is a formal @b<in> parameter specified by an
+@fa<access_definition>. An access parameter is of an anonymous access type (see
+3.10). Access parameters allow dispatching calls to be controlled by access
+values.
+
+!corrigendum 8.5.1(4)
+
+@drepl
+The renamed entity shall be an object.
+@dby
+The renamed entity shall be an object.
+In the case where the type is defined by an @fa<access_definition>,
+the renamed entity shall be of an access-to-constant type if and
+only if the @fa<access_definition> defines an access-to-constant type.
+
+!corrigendum 8.6(25)
+
+@drepl
+@xinbull<when @i<T> is an anonymous access type (see 3.10) with designated
+type @i<D>, to an access-to-variable type whose designated type is @i<D>'Class
+or is covered by @i<D>.>
+@dby
+@xinbull<when @i<T> is an anonymous access-to-object type (see 3.10) with
+designated type @i<D>, to an access-to-object type whose designated type is
+@i<D>'Class or is covered by @i<D>, and that is access-to-constant only if
+@i<T> is access-to-constant.>
+
+!corrigendum 12.5.1(10)
+
+@dinsa
+@xbullet<If the ancestor subtype is an unconstrained discriminated subtype,
+then the actual shall have the same number of discriminants, and each
+discriminant of the actual shall correspond to a discriminant of the ancestor,
+in the sense of 3.7.>
+@dinst
+@xbullet<If the ancestor subtype is an access subtype, the actual subtype shall
+exclude null if and only if the ancestor subtype excludes null.>
+
+!corrigendum 12.5.4(4)
+
+@drepl
+If and only if the @fa<general_access_modifier> @b<constant> applies to the
+formal, the actual shall be an access-to-constant type. If the
+@fa<general_access_modifier> @b<all> applies to the formal, then the actual
+shall be a general access-to-variable type (see 3.10).
+@dby
+If and only if the @fa<general_access_modifier> @b<constant> applies to the
+formal, the actual shall be an access-to-constant type. If the
+@fa<general_access_modifier> @b<all> applies to the formal, then the actual
+shall be a general access-to-variable type (see 3.10). If and only if the
+formal subtype excludes null, the actual subtype shall exclude null.
+
 !ACATS test
 
 Tests should be created to check on the implementation of this feature.
@@ -385,6 +674,62 @@
 
 The wording change isn't instantly obvious, so I think I'd prefer a new
 version from you.
+
+*************************************************************
+
+From: Javier Miranda
+Sent: Wednesday, January 7, 2004  12:29 PM
+
+In file AI-00231.TXT (date 03-10-22) it is said:
+
+   access_definition ::=
+      [null_exclussion] ACCESS general_access_modifier subtype_mark
+
+However, in AI-00254 (date 03-11-11) it is said:
+
+   access_definition ::=
+      [null_exclussion] ACCESS [general_access_modifier] subtype_mark |
+      ...
+
+It seems to me that this second alternative is the right one (to be
+compatible with Ada95). In addition both proposals should have the same
+rule. Is this a bug in AI-00231?
+
+*************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, January 7, 2004  1:00 PM
+
+This looks like a bug in AI-00231.  Certainly there's no intent
+to create an incompatibility by requiring an explicit modifier.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 7, 2004  10:26 PM
+
+The version that Tucker handed out at the meeting (AI-00231/07) doesn't have
+this problem. I didn't post it in the hopes of saving redundant effort, but
+it is now available in the version control system (only - not in the .ZIP
+files).
+
+*************************************************************
+
+From: Javier Miranda
+Sent: Thursday, January 8, 2004  3:33 AM
+
+Thanks Randy. In the future I will use the versions
+available in the version control system to avoid generating
+unnecessary noise!
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 8, 2004  11:55 AM
+
+That's always preferrable, but it wouldn't have helped in this case, because
+I didn't actually send the changes up until I saw your note. So only people
+who were at the meeting had the new version.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent