CVS difference for ai12s/ai12-0377-1.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0377-1.txt

--- ai12s/ai12-0377-1.txt	2020/06/08 00:25:36	1.7
+++ ai12s/ai12-0377-1.txt	2020/06/17 00:20:22	1.8
@@ -1,9 +1,11 @@
-!standard 6.4.1(5.1/4)                                  20-06-07  AI12-0377-1/02
+!standard 6.4.1(5.1/4)                                  20-06-15  AI12-0377-1/03
 !standard 6.4.1(5.2/4)
 !standard 6.4.1(5.3/4)
 !standard 6.4.1(13.2/4)
 !standard 6.4.1(13.3/4)
-!class Amendment 20-04-20
+!class binding interpretation 20-06-13
+!status Amendment 1-2012 20-06-15
+!status ARG Approved 13-0-0  20-06-13
 !status work item 20-04-20
 !status received 20-04-14
 !priority Low
@@ -16,7 +18,7 @@
 not. Program_Error is raised if this occurs where one of the types is a
 generic formal type.
 Consider this example:
@@ -49,8 +51,10 @@
 object, which is the sort of thing that shouldn't normally be possible for an
 object whose type has a specified Default_Value.
+Should this be revisited? (Yes.)
 (See Summary.)
@@ -90,18 +94,21 @@
 "Deinitialization" here cannot introduce an invalid value into an object
-that the compiler assumed to be valid (the conversion back to
+that the compiler assumed to be valid; the conversion back to
 the actual would still do a subtype check, which would cause Constraint_Error
 if the value is invalid. Note that the check would be required since one
-cannot assume anything about out parameters). Even so, it seems dangerous
-enough that we should take steps to prevent it.
+cannot assume anything about out parameters. Even so, it seems dangerous
+enough that we should take steps to prevent it. AI12-0074-1 has examples
+of "deinitialization" causing problems, particularly with "unused" out
+parameters which only return values in some cases.
 The best solution is to make any view conversion used in an out parameter
 illegal if one type has Default_Value and the other does not. Note
 that the repeal of 13.1(10/3) by AI12-0376-1 means that having the types be
 related no longer prevents problems (as a derived type can define a
 Default_Value when the parent type does not have one), so we would have to do
-something with this rule in any case.
+something with this rule in any case. The relationship still has value, though
+as the set of values will still be related.
 The alternative of passing the default value in problematic cases would make
 the deinitialization noted in the problem worse (since it would clobber the

Questions? Ask the ACAA Technical Agent