CVS difference for ais/ai-00409.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00409.txt

--- ais/ai-00409.txt	2005/02/08 07:12:41	1.2
+++ ais/ai-00409.txt	2005/04/13 05:37:22	1.3
@@ -1,5 +1,12 @@
-!standard 6.3.1 (15)                                   05-02-07  AI95-00409/01
+!standard 6.3.1 (15)                                   05-03-09  AI95-00409/02
+!standard 6.3.1 (16)
+!standard 8.5.1 (2)
+!standard 8.5.1 (3)
+!standard 8.5.1 (4)
+!standard 8.6 (25)
 !class amendment 05-02-07
+!status Amendment 200Y 05-03-09
+!status ARG Approved 8-0-2  05-02-13
 !status work item 05-02-07
 !status received 05-02-07
 !priority High
@@ -8,8 +15,8 @@
 
 !summary
 
-Type conformance requires access-to-subp access parameters to have type
-conformant designated profiles. For mode conformance, access-to-subp
+Type conformance requires access-to-subprogram access parameters to have type
+conformant designated profiles. For mode conformance, access-to-subprogram
 access parameters should have subtype conformant designated profiles
 and matching convention (e.g. protectedness). For subtype conformance,
 subtypes of corresponding access parameters should statically match.
@@ -29,46 +36,58 @@
 This should be relaxed to be based on type conformance,
 and legality rules added as necessary to ensure subtype
 conformance. This is relevant for resolution on renaming
-of an object of an anonymous access-to-subp type, as well
+of an object of an anonymous access-to-subprogram type, as well
 as on assignment.
 
 !wording
 
+Change the paragraph added after 6.3.1(13) by AI-254 to:
+
+    The calling convention for an access parameter {or access result}
+    of an access-to-subprogram type is protected if the reserved word protected
+    appears in its definition and otherwise is the convention of the subprogram
+    that contains the parameter.
+
 Change 6.3.1(15):
 
-    ... or, for access parameters, corresponding designated types
-    are the same{, or corresponding designated profiles are type
+    ... or, for access parameters {or access results}, corresponding designated
+    types are the same{, or corresponding designated profiles are type
     conformant}.
 
-Change 6.3.1(16/2):
+Change 6.3.1(16) (as modified by AI-318-2):
 
     ... and, for access parameters or access result types, the designated
     subtypes statically match{, or the designated profiles are
     subtype conformant}.
 
-
 Disallow explicit specification of null exclusion in renaming,
-by adding a syntax rule after 8.5.1(2/2):
+by adding a syntax rule after 8.5.1(2):
 
     The access_definition shall not include a null_exclusion.
 
-Replace last part of 8.5.1(3/2):
+Change the last part of 8.5.1(3) (as modified by AI-230 and AI-254):
 
     ... or in the case where the type is defined by an
-    access_definition, to an anonymous access type
-    with the same designated type or designated profile
-    that is type conformant with that of the access_definition.
-
-Replace last part of 8.5.1(4/2)
-
-    ... In the case where the type is defined by an access_definition,
-    the type of the renamed object and the type defined
-    by the access_definition shall have statically matching
-    designated subtypes, or subtype conformant designated
-    profiles. For the anonymous access-to-object case,
-    the two types shall either both or neither be
-    access-to-constant types.
+    access_definition, to {an}[a specific] anonymous access type
+    to a specific anonymous access type which in the case of an
+    access-to-object type shall have the same designated type as that of the
+    access_definition and in the case of an access-to-subprogram type shall
+    have a designated profile which is [subtype]{type} conformant with
+    that of the access_definition.
+
+Replace last part of 8.5.1(4) (as modified by AI-231):
+
+    ... In the case where the type is defined by an access_definition, the type
+    of the renamed object and the type defined by the access_definition:
+    * shall both be access-to-object types with statically matching designated
+      subtypes and with both or neither being access-to-constant types; or
+    * shall both be access-to-subprogram types with subtype conformant
+      designated profiles.
+
 
+Change 8.5.1(6):
+    ... similarly, the {null exclusion or} constraints that apply ...
+
   AARM NOTE:
     Explicit null_exclusion is not permitted. Null exclusiveness
     need not match, in the same way that constraints need not match,
@@ -76,20 +95,15 @@
     the renamed entity, inheriting the original properties.
 
 
-Change 8.5.1(6/2):
-    ... similarly, the {null exclusion or} constraints that apply ...
+Remove from 8.6(25) (as modified by AI-230, AI-231, and AI-254):
 
+  ... [, and that is access-to-constant only if T is access-to-constant]; or
 
-Remove from 8.6(25/2):
+Change the paragraph assed after 8.6(25) by AI-254:
 
-  ... [, and that is access-to-constant only if T is access-to-constant.]
-
-Change 8.6(25.1/2):
-
    ... whose designated profile is [subtype]{type}-conformant with that of T.
 
 
-
 !discussion
 
 The originally proposed name resolution rules don't correspond to
@@ -116,16 +130,122 @@
 
 So whatever we decide here ought to correlate well with what we decide
 for type conformance. As suggested above, probably the expected type
-should resolve anonymous access-to-subp operands based on type
+should resolve anonymous access-to-subprogram operands based on type
 conformance, rather than subtype conformance. That seems more
 consistent with resolving anon access-to-object based on designated
 *type* rather than *subtype*. They should also not consider
-acc-to-constant vs. acc-to-variable for anonymous access types. Also,
+access-to-constant vs. access-to-variable for anonymous access types. Also,
 since presumably a value of an access-to-variable type can be implicitly
 converted to an anonymous access-to-constant type, it doesn't seem to
 make sense to consider that during expected type resolution.
+
+
+!corrigendum 6.3.1(13)
+
+@dinsa
+@xbullet<The default calling convention is @i<entry> for an entry.>
+@dinst
+@xbullet<The calling convention for an access parameter or access result of an
+access-to-subprogram type is @i<protected> if the reserved word @b<protected>
+appears in its definition and otherwise is the convention of the subprogram
+that contains the parameter.>
+
+
+!corrigendum 6.3.1(15)
+
+@drepl
+Two profiles are @i<type conformant> if they have the same number of
+parameters, and both have a result if either does, and corresponding parameter
+and result types are the same, or, for access parameters, corresponding
+designated types are the same.
+@dby
+Two profiles are @i<type conformant> if they have the same number of
+parameters, and both have a result if either does, and corresponding parameter
+and result types are the same, or, for access parameters or access results,
+corresponding designated types are the same, or corresponding designated
+profiles are type conformant.
+
+!corrigendum 6.3.1(16)
+
+@drepl
+Two profiles are @i<mode conformant> if they are type-conformant, and
+corresponding parameters have identical modes, and, for access parameters, the
+designated subtypes statically match.
+@dby
+Two profiles are @i<mode conformant> if they are type-conformant,
+corresponding parameters have identical modes, and, for access parameters or
+access result types, the designated subtypes statically match, or the
+designated profiles are subtype conformant.
+
+!corrigendum 8.5.1(2)
+
+@dinsa
+@xcode<@fa<object_renaming_declaration ::=
+    defining_identifier : subtype_mark >@ft<@b<renames>>@fa< object_name;>>
+@dinst
+The @fa<access_definition> shall not include a @fa<null_exclusion>.
+
+!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 which in the case
+of an access-to-object type shall have the same designated type as that of the
+@fa<access_definition> and in the case of an access-to-subprogram type shall
+have a designated profile which is type conformant with that of the
+@fa<access_definition>.
+
+!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 type of the renamed object and the type defined by the access_definition:
+@xbullet<shall both be access-to-object types with statically matching designated
+subtypes and with both or neither being access-to-constant types; or>
+@xbullet<shall both be access-to-subprogram types with subtype conformant
+designated profiles.>
+
+!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 null exclusion or 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).
+
+
+!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 a specific 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>; or>
+@xinbull<when @i<T> is an anonymous access-to-subprogram type (see 3.10), to
+an access-to-subprogram type whose designated profile is type-conformant
+with that of @i<T>.>
 
---!corrigendum
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent