CVS difference for ai12s/ai12-0378-1.txt
--- ai12s/ai12-0378-1.txt 2020/07/09 07:15:40 1.7
+++ ai12s/ai12-0378-1.txt 2020/09/02 03:55:24 1.8
@@ -1,4 +1,4 @@
-!standard 6.4.1(13/3) 20-07-07 AI12-0378-1/05
+!standard 6.4.1(13/3) 20-08-28 AI12-0378-1/06
!standard 6.4.1(18/3)
!class Binding Interpretation 20-06-18
!status Amendment 1-2012 20-07-07
@@ -9,12 +9,10 @@
!subject View conversions and out parameters of access types revisited
!summary
-An actual of an out parameter that is a view conversion of an access
-type is not illegal if the types are not related, rather null is passed
-if the access value could violate any (runtime) tag check or
-accessibility check that applies to the formal. Constraints, predicates,
-and null exclusions are always ignored for out parameters of an access
-type.
+In the case of an actual out parameter that is a view conversion between two
+access types with no common ancestor, an implementation permission is granted
+allowing implementations to pass in the null value of the formal parameter
+type instead of the value of the actual parameter.
!question
@@ -30,60 +28,38 @@
!wording
-Replace 6.4.1(13/3) with the following paragraphs:
- * For an access type:
+Replace 6.4.1(13/3) with:
- * if the designated type of the actual is a class-wide type T'Class
- and the designated type of the formal is neither an ancestor of T,
- nor a class-wide type that covers T, then the formal parameter
- is initialized to the null value of the formal type;
-
-
- * if the actual is a stand-alone object of an anonymous access type,
- and the accessibility level of the formal type is not library
- level, then the formal parameter is initialized to the null value
- of the formal type;
-
- * if the call is within the body of an instance of a generic unit,
- the actual or the formal type is descended from a generic formal
- access type of the generic unit, and the actual and formal types
- neither share an ancestor nor is the formal type accessibility at
- library level, then the formal parameter is initialized to the null
- value of the formal type;
-
-
- * otherwise, the formal parameter is initialized to the value of the
- actual parameter, without checking that the value satisfies any
- constraint.
-
- In all of the above cases, no check is performed for any predicate
- or exclusion of the null value that might apply to the formal
- type.
-
- AARM Implementation Note: This rule means that any tag checks
- and accessibility checks can be assumed to pass for an out
- parameter, but constraints, null exclusions, and predicates cannot
- be assumed unless the compiler can prove that the object has been
- previously written within the subprogram.
-
+ * For an access type, the formal parameter is initialized from the
+ value of the actual, without checking whether the
+ value satisfies any constraints, predicates, or null exclusions,
+ but including any [Redundant: dynamic] accessibility checks associated
+ with a conversion to the type of the formal parameter.
+
+ AARM Ramification: The permission to pass *null* can be used in any
+ case where an accessibility check could fail, rather than making a
+ check.
+
Add after RM 6.4.1(18/3):
- Implementation Permission
+ Implementation Permissions
- For an OUT parameter of an access type, if the representation of the
- actual type and the formal type differ, and there are values of the
- actual type that cannot be represented as values of the formal type,
- the implementation may initialize the formal parameter with the null
- value of the formal type.
+ If the actual parameter in a parameter_association with mode *out*
+ is a view conversion between two access types that do not share a common
+ ancestor type, the implementation may pass in the null value of the
+ type of the formal parameter instead of the value of the actual
+ parameter. It is implementation-defined under what circumstances the
+ implementation passes in the null value.
Add after AARM 6.4.1(18.i/3):
Inconsistencies with Ada 2012
- Correction: Added rules so that value passed into an out parameter for access
- types is well-defined in the case of a view conversion. Null will be passed in
- for conversions that may have problematic accessibility or tags. If the
- accessibility or tag check(s) would have passed, and the out parameter is
+ Correction: Added a permission to pass null so that value passed into
+ an out parameter for access types is well-defined in the case of a view
+ conversion. Null may be passed for any view conversion between unrelated
+ access types; this is important for conversions that may have problematic
+ accessibility or tags. If the permission is used and the out parameter is
read before it is written (perhaps to read a bound or discriminant),
Constraint_Error may be raised by Ada 202x when it would not have been in
Ada 2012. Additionally, if the called subprogram does not write the out
@@ -204,16 +180,29 @@
made the runtime model harder to describe and to implement, for what are
considered corner cases. We also considered a legality rule disallowing
problematic cases, but we felt the potential incompatibilities would be
-worse.
+worse. A compile-time rule that would pass null in only the problematic
+cases was very complicated.
+
+So we settled on an Implementation Permission to allow implementations
+to pass null in cases that might be problematic. If the implementation
+doesn't pass null, then it needs to make the accessibility and tag checks.
+We allow the "tripping hazard" for accessibility checks in that case,
+but the tag checks have to be made at each use if null is not passed in.
+The Implementation Permission includes the magic words
+"implementation-defined" in order to trigger a documentation requirement
+as to when null will be passed.
---
As far as converting between access types with different
-representations, we provide an implementation permission to pass null in
-such a case if it involves an OUT parameter. We don't provide any
-permission or suggestion related to normal conversions or IN OUT
-parameters in such a case. We presume implementations will do the
-(implementation-defined) "right thing" in such cases.
+representations, the implementation permission also allows passing
+null if it involves an out parameter with unrelated types.
+We don't provide any permission or suggestion related to normal
+conversions or IN OUT parameters in such a case. We presume
+implementations will do the (implementation-defined) "right thing"
+in such cases. Similarly, we expect the implementation will do
+the "right thing" for related types (most likely, not allowing
+different representations that could be problematic).
!corrigendum 6.4.1(13/3)
@@ -222,31 +211,11 @@
value of the actual, without checking that the value satisfies any
constraint, any predicate, or any exclusion of the null value;>
@dby
-@xinbull<For an access type:>
-
-@xi2bull<if the designated type of the actual is a class-wide type @i<T>'Class
- and the designated type of the formal is neither an ancestor of @i<T>,
- nor a class-wide type that covers @i<T>, then the formal parameter
- is initialized to the null value of the formal type;>
-
-@xi2bull<if the actual is a stand-alone object of an anonymous access type,
- and the accessibility level of the formal type is not library
- level, then the formal parameter is initialized to the null value
- of the formal type;>
-
-@xi2bull<if the call is within the body of an instance of a generic unit,
- the actual or the formal type is descended from a generic formal
- access type of the generic unit, and the actual and formal types
- neither share an ancestor nor is the formal type accessibility at
- library level, then the formal parameter is initialized to the null
- value of the formal type;>
-
-@xi2bull<otherwise, the formal parameter is initialized to the value of the
- actual parameter, without checking that the value satisfies any
- constraint.>
-
-@xindent<In all of the above cases, no check is performed for any predicate
-or exclusion of the null value that might apply to the formal type.>
+@xinbull<For an access type, the formal parameter is initialized from the
+value of the actual, without checking whether the
+value satisfies any constraints, predicates, or null exclusions,
+but including any dynamic accessibility checks associated
+with a conversion to the type of the formal parameter.>
!corrigendum 6.4.1(18/3)
@@ -258,12 +227,14 @@
corresponding callable construct).
@dinst
@s8<@i<Implementation Permissions>>
+
+If the actual parameter in a @fa<parameter_association> with mode @b<out>
+is a view conversion between two access types that do not share a common
+ancestor type, the implementation may pass in the null value of the
+type of the formal parameter instead of the value of the actual
+parameter. It is implementation-defined under what circumstances the
+implementation passes in the null value.
-For an @b<out> parameter of an access type, if the representation of the
-actual type and the formal type differ, and there are values of the
-actual type that cannot be represented as values of the formal type,
-the implementation may initialize the formal parameter with the null
-value of the formal type.
!ASIS
Questions? Ask the ACAA Technical Agent