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

--- ai12s/ai12-0377-1.txt	2020/06/02 23:35:18	1.6
+++ ai12s/ai12-0377-1.txt	2020/06/08 00:25:36	1.7
@@ -1,4 +1,4 @@
-!standard 6.4.1(5.1/4)                                  20-04-29  AI12-0377-1/01
+!standard 6.4.1(5.1/4)                                  20-06-07  AI12-0377-1/02
 !standard 6.4.1(5.2/4)
 !standard 6.4.1(5.3/4)
 !standard 6.4.1(13.2/4)
@@ -11,9 +11,9 @@
 !subject  View conversions and out parameters of types with Default_Value revisited
 !summary
 
-An actual of an out parameter that is a view conversion is illegal if either 
-the target or operand type has Default_Value specified while the other does 
-not. Program_Error is raised if this occurs where one of the types is a 
+An actual of an out parameter that is a view conversion is illegal if either
+the target or operand type has Default_Value specified while the other does
+not. Program_Error is raised if this occurs where one of the types is a
 generic formal type.
 
 !problem
@@ -38,14 +38,14 @@
      P (Integer (Y));  -- Deinitialize Y?
    end View_Conversion_With_Default_Value;
 
-Even though the type of X and Y has specified Default_Value, the value of the 
-actual isn't copied into the formal in this case (it falls under the rule of 
-6.4.1(15)), leaving the formal parameter uninitialized. Upon return, the value 
-of the formal will be converted to Defaulted_Integer and assigned to the actual 
+Even though the type of X and Y has specified Default_Value, the value of the
+actual isn't copied into the formal in this case (it falls under the rule of
+6.4.1(15)), leaving the formal parameter uninitialized. Upon return, the value
+of the formal will be converted to Defaulted_Integer and assigned to the actual
 object.
 
-If the formal wasn't assigned to within the procedure, as in the above example, 
-then the (uninitialized) value that comes back will deinitialize the actual 
+If the formal wasn't assigned to within the procedure, as in the above example,
+then the (uninitialized) value that comes back will deinitialize the actual
 object, which is the sort of thing that shouldn't normally be possible for an
 object whose type has a specified Default_Value.
 
@@ -57,44 +57,50 @@
 
 Replace 6.4.1(5.1/3) with:
 
-If the mode is out, the actual parameter is a view conversion, and the type of 
+If the mode is out, the actual parameter is a view conversion, and the type of
 the formal parameter is a scalar type, then either:
-* neither the target nor operand type have the Default_Value aspect specified; or
-* there shall exist a type (other than a root numeric type) that is an ancestor of
-  both the target type and the operand type, and both the target and operand types
-  have the Default_Value aspect specified. 
 
-[Author's note: This removes the access part of this rule, and makes a 
+  * the target and operand type both do not have the Default_Value aspect
+    specified; or
+
+  * the target and operand type both have the Default_Value aspect
+    specified, and there shall exist a type (other than a root numeric
+    type) that is an ancestor of both the target type and the operand type.
+
+[Editor's note: This removes the access part of this rule, and makes a
 version apply to all view conversions.]
+
+Revert 6.4.1(13.1/4) to its previous version, namely:
 
-Revert 6.4.1(13.1/4) to its previous version.
+  For a scalar type that has the Default_Value aspect specified, the
+  formal parameter is initialized from the value of the actual, without
+  checking that the value satisfies any constraint or any predicate.
 
 Delete 6.4.1(13.2-13.4/4), and AARM 6.4.1(13.d/4).
 
 Add after 6.4.1(15):
 
 * Furthermore, if the type is a scalar type, and the actual parameter is a
-  view conversion, then if neither:
-  * neither the target nor operand type have the Default_Value aspect specified; or
-  * there exists a type (other than a root numeric type) that is an ancestor of
-    both the target type and the operand type, and both the target and operand types
-    have the Default_Value aspect specified
-  then Program_Error is raised;
+  view conversion, then Program_Error is raised if either the target or
+  the operand type has the Default_Value aspect specified, unless they
+  both have the Default_Value aspect specified, and there is a type
+  (other than a root numeric type) that is an ancestor of both the
+  target type and the operand type.
 
 !discussion
 
-"Deinitialization" here cannot introduce an invalid value into an object 
-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 
+"Deinitialization" here cannot introduce an invalid value into an object
+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.
 
-The best solution is to make any view conversion used in an out parameter 
+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 
+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.
 
 The alternative of passing the default value in problematic cases would make
@@ -102,7 +108,6 @@
 current value of the object unconditionally, even if it would be in range),
 so that is not a viable solution to this problem.
 
-
 !ASIS
 
 No ASIS effect.
@@ -117,9 +122,9 @@
 From: Gary Dismukes
 Sent: Tuesday, April 14, 2020  5:43 PM
 
-Recently, while fixing a GNAT problem related to passing view conversions to 
+Recently, while fixing a GNAT problem related to passing view conversions to
 out-mode parameters when Default_Value is involved (related to the rules added
-in AI12-0074), it occurred to me that there's a similar situation that can 
+in AI12-0074), it occurred to me that there's a similar situation that can
 arise when the formal type doesn't have aspect Default_Value, but the type of
 the operand of the view conversion does have the aspect.  (AI12-0074 addressed
 the case of formal types that specific Default_Value, requiring the type of an
@@ -146,39 +151,39 @@
      P (Integer (Y));  -- Deinitialize Y?
    end View_Conversion_With_Default_Value;
 
-Even though the type of X and Y has specified Default_Value, the value of the 
-actual isn't copied into the formal in this case (it falls under the rule of 
-6.4.1(15)), leaving the formal parameter uninitialized. Upon return, the value 
-of the formal will be converted to Defaulted_Integer and assigned to the actual 
+Even though the type of X and Y has specified Default_Value, the value of the
+actual isn't copied into the formal in this case (it falls under the rule of
+6.4.1(15)), leaving the formal parameter uninitialized. Upon return, the value
+of the formal will be converted to Defaulted_Integer and assigned to the actual
 object.
 
-If the formal wasn't assigned to within the procedure, as in the above example, 
-then the (uninitialized) value that comes back will deinitialize the actual 
+If the formal wasn't assigned to within the procedure, as in the above example,
+then the (uninitialized) value that comes back will deinitialize the actual
 object, which is the sort of thing that shouldn't normally be possible for an
 object whose type has a specified Default_Value.
 
-You could argue that you shouldn't have a formal of mode out that isn't 
-assigned to, but that's kind of beside the point, because the normal guarantee 
-of Default_Value, that variables of the type always have a good value, is 
-violated in this case, so we clearly have a safety hazard. To avoid this, the 
-rules either need to require the value of the actual to be assigned to the 
-formal going in, or such a conversion needs to be rejected.  I was initially 
-leaning towards the former, but Tuck has convinced me that this should be 
-illegal.  Basically we don't want to impose the penalty of preventing an 
-optimization like transforming a procedure with a single elementary out formal 
-into a function returning the parameter, just to protect against what is going 
-to be the rare case of passing a view conversion of an operand with 
+You could argue that you shouldn't have a formal of mode out that isn't
+assigned to, but that's kind of beside the point, because the normal guarantee
+of Default_Value, that variables of the type always have a good value, is
+violated in this case, so we clearly have a safety hazard. To avoid this, the
+rules either need to require the value of the actual to be assigned to the
+formal going in, or such a conversion needs to be rejected.  I was initially
+leaning towards the former, but Tuck has convinced me that this should be
+illegal.  Basically we don't want to impose the penalty of preventing an
+optimization like transforming a procedure with a single elementary out formal
+into a function returning the parameter, just to protect against what is going
+to be the rare case of passing a view conversion of an operand with
 Default_Value.
 
-So it seems that we need to augment the rules of 6.4.1(5.1-5.3), which require 
-the type of the operand of a view conversion to have Default_Value when the 
-formal's type has Default_Value.  We need to also disallow the case where a 
-view conversion operand's type has Default_Value but the formal's type 
+So it seems that we need to augment the rules of 6.4.1(5.1-5.3), which require
+the type of the operand of a view conversion to have Default_Value when the
+formal's type has Default_Value.  We need to also disallow the case where a
+view conversion operand's type has Default_Value but the formal's type
 doesn't.
 
-I believe we'll also need to add something along the lines of the rules in 
-6.4.1(13.1-13.4) that require Program_Error be raised, to address call cases 
-within generic bodies when formal types are involved (those rules were also 
+I believe we'll also need to add something along the lines of the rules in
+6.4.1(13.1-13.4) that require Program_Error be raised, to address call cases
+within generic bodies when formal types are involved (those rules were also
 added by AI12-0074).
 
 ****************************************************************
@@ -188,9 +193,9 @@
 
 We have discussed this internally at AdaCore, and concluded that we should
 make it illegal to pass a scalar type with Default_Value in a view conversion
-to an OUT formal parameter without a Default_Value.  Requiring "copy in" is 
+to an OUT formal parameter without a Default_Value.  Requiring "copy in" is
 not practical given the way that OUT parameters of a scalar type are sometimes
-implemented (such as transforming the procedure to a function and returning 
+implemented (such as transforming the procedure to a function and returning
 the OUT parameter as a function result).
 
 ****************************************************************
@@ -198,28 +203,28 @@
 From: Randy Brukardt
 Sent: Tuesday, April 21, 2020  7:57 PM
 
-> Recently, while fixing a GNAT problem related to passing view 
-> conversions to out-mode parameters when Default_Value is 
-> involved (related to the rules added in AI12-0074), it 
-> occurred to me that there's a similar situation that can 
-> arise when the formal type doesn't have aspect Default_Value, 
-> but the type of the operand of the view conversion does have 
-> the aspect.  (AI12-0074 addressed the case of formal types 
-> that specific Default_Value, requiring the type of an operand 
-> of a view conversion actual to also specify Default_Value, 
+> Recently, while fixing a GNAT problem related to passing view
+> conversions to out-mode parameters when Default_Value is
+> involved (related to the rules added in AI12-0074), it
+> occurred to me that there's a similar situation that can
+> arise when the formal type doesn't have aspect Default_Value,
+> but the type of the operand of the view conversion does have
+> the aspect.  (AI12-0074 addressed the case of formal types
+> that specific Default_Value, requiring the type of an operand
+> of a view conversion actual to also specify Default_Value,
 > and this is sort of the reverse of that.)
 
-I'm not throughly convinced that this problem (in any form) is worth worrying 
-about, since it can't cause an invalid value to be introduced to the program 
+I'm not throughly convinced that this problem (in any form) is worth worrying
+about, since it can't cause an invalid value to be introduced to the program
 (at least in a correct implementation). If the implementation is assuming that
-the actual object is valid, then a constraint check is necessary at the back 
-assignment and that would prevent any invalid values from being stored. The 
-value would indeed be junk, but that's what was written (and it happens for 
+the actual object is valid, then a constraint check is necessary at the back
+assignment and that would prevent any invalid values from being stored. The
+value would indeed be junk, but that's what was written (and it happens for
 all scalar out parameters).
 
-Anyway, assuming that we do want to keep this illegal in any case, we need to 
-cover *this* case as well. Attached is an attempt at doing that, and also 
-handling the access problem (with a solution close to what GNAT is currently 
+Anyway, assuming that we do want to keep this illegal in any case, we need to
+cover *this* case as well. Attached is an attempt at doing that, and also
+handling the access problem (with a solution close to what GNAT is currently
 doing).
 
 I suspect that the AI and especially the wording will need some wordsmithing.
@@ -235,30 +240,30 @@
 
 Wording suggestion:
 
-If the mode is out, the actual parameter is a view conversion, and the type 
+If the mode is out, the actual parameter is a view conversion, and the type
 of the formal parameter is a scalar type, then either:
 
   * the target and operand type do not have the Default_Value aspect
-    specified; or 
-  
+    specified; or
+
   * the target and operand type both have the Default_Value aspect
     specified, and there shall exist a type (other than a root numeric
     type) that is an ancestor of both the target type and the operand type.
-    
+
 ****************************************************************
 
 From: Randy Brukardt
 Sent: Wednesday, April 29, 2020  3:32 PM
 
-BTW, Claire, if you could provide an example of the problem that you were 
+BTW, Claire, if you could provide an example of the problem that you were
 concerned about with the AI12-0377-1 proposal, it would be appreciated.
 
-My incomplete understanding of your concern made it appear that the only 
+My incomplete understanding of your concern made it appear that the only
 solution would be to ban all view conversions of types with Default_Value
-unless the defaults were the same. That would prevent declaring (or at 
-least using) any derived types with different defaults (if there are 
-primitive operations) -- but that was specifically the case that Arno wanted 
-us to allow as he has customer code that depends upon it. It doesn't seem 
+unless the defaults were the same. That would prevent declaring (or at
+least using) any derived types with different defaults (if there are
+primitive operations) -- but that was specifically the case that Arno wanted
+us to allow as he has customer code that depends upon it. It doesn't seem
 possible to thread that needle!
 
 ****************************************************************
@@ -269,11 +274,11 @@
 >     If the mode is out, the actual parameter is a view conversion, and
 >     the type of
 >     the formal parameter is a scalar type, then either:
-> 
+>
 >       * the target and operand type do not have the Default_Value aspect
 >         specified; or
 
-I doubt that a Float and a Boolean, both without a Default_Value, are o.k. 
+I doubt that a Float and a Boolean, both without a Default_Value, are o.k.
 in a view conversion :-)  (There is a convertability constraint missing).
 
 ****************************************************************
@@ -285,15 +290,15 @@
 >>    If the mode is out, the actual parameter is a view conversion, and
 >>    the type of
 >>    the formal parameter is a scalar type, then either:
->> 
+>>
 >>      * the target and operand type do not have the Default_Value aspect
 >>        specified; or
-> 
-> I doubt that a Float and a Boolean, both without a Default_Value, are 
-> o.k. in a view conversion :-)  (There is a convertability constraint 
+>
+> I doubt that a Float and a Boolean, both without a Default_Value, are
+> o.k. in a view conversion :-)  (There is a convertability constraint
 > missing).
- 
-This is the dynamic semantics.  The legality rules have already done their 
+
+This is the dynamic semantics.  The legality rules have already done their
 thing, so we only need to explain what happens with legal view conversions.
 
 ****************************************************************
@@ -301,21 +306,21 @@
 From: Erhard Ploedereder
 Sent: Thursday, April 30, 2020  8:46 AM
 
->> I doubt that a Float and a Boolean, both without a Default_Value, are 
->> o.k. in a view conversion :-)  (There is a convertability constraint 
+>> I doubt that a Float and a Boolean, both without a Default_Value, are
+>> o.k. in a view conversion :-)  (There is a convertability constraint
 >> missing).
 >>
 > This is the dynamic semantics.  The legality rules have already done their
 > thing, so we only need to explain what happens with legal view conversions.
-> 
+>
 
 o.k. Understood. Or maybe only half of it, because the next bullet
-   
+
 >   * the target and operand type both have the Default_Value aspect
 >     specified, and there shall exist a type (other than a root numeric
 >     type) that is an ancestor of both the target type and the operand type.
 
-includes a compatibility constraint as well, which ought to have been checked 
+includes a compatibility constraint as well, which ought to have been checked
 by static semantics as well. (That part of the wording triggered my comment in
 the first place, a "why here, but not there?"-question).
 
@@ -324,10 +329,10 @@
 From: Claire Dross
 Sent: Thursday, April 30, 2020  3:28 AM
 
-Honestly, I think I will need some help to understand the rationale of the 
-rules for passing of OUT parameters with default values. Yesterday, we said 
+Honestly, I think I will need some help to understand the rationale of the
+rules for passing of OUT parameters with default values. Yesterday, we said
 that we did not want a null procedure to deinitialize a scalar variable whose
-type has a Default_Value aspect. But I don't really understand why. Surely 
+type has a Default_Value aspect. But I don't really understand why. Surely
 null procedures will deinitialize variables which don't have this aspect, and
 this is a bounded error, right? So to say it otherwise, I think
 
@@ -336,8 +341,8 @@
       null;
    end P;
 
-where T is an integer type without a Default_Value is wrong. Why should we do 
-anything to support correctly (reject correctly) the corner case of call to 
+where T is an integer type without a Default_Value is wrong. Why should we do
+anything to support correctly (reject correctly) the corner case of call to
 such a function on a view conversion?
 
 ****************************************************************
@@ -345,9 +350,9 @@
 From: Jeff Cousins
 Sent: Thursday, April 30, 2020  3:57 AM
 
-To be honest, I agree with Claire. To not assign anything to an out parameter 
-is plain wrong so I don't see why we should go to a lot of trouble to get it 
-to return something sensible in certain circumstances. (A former colleague 
+To be honest, I agree with Claire. To not assign anything to an out parameter
+is plain wrong so I don't see why we should go to a lot of trouble to get it
+to return something sensible in certain circumstances. (A former colleague
 used somewhat stronger language).
 
 ****************************************************************
@@ -355,7 +360,7 @@
 From: Tucker Taft
 Sent: Thursday, April 30, 2020  8:08 AM
 
-One of the fundamental "promises" associated with types with a default, is 
+One of the fundamental "promises" associated with types with a default, is
 they never become de-initialized.
 
 ****************************************************************
@@ -363,17 +368,17 @@
 From: Erhard Ploedereder
 Sent: Thursday, April 30, 2020  8:28 AM
 
-To me, the foremost reason in favor of the AI is that I would like to rely on 
-the fact that any variable with specified default_value is guaranteed to 
-always be initialized. No buts, ifs, and whens, or special cases or corners 
+To me, the foremost reason in favor of the AI is that I would like to rely on
+the fact that any variable with specified default_value is guaranteed to
+always be initialized. No buts, ifs, and whens, or special cases or corners
 that I need to check for after all.
 
 Just like non-null types .... no buts, ifs, except whens....
 
-And as to risk: a deinitialized Integer is almost as bad as a deinitialized 
-access value. All I need to do is use it as index into an array, where 
-matching subtype properties are statically established and hence the index 
-check unnecessary. (I can even exploit that security hole by placing the 
+And as to risk: a deinitialized Integer is almost as bad as a deinitialized
+access value. All I need to do is use it as index into an array, where
+matching subtype properties are statically established and hence the index
+check unnecessary. (I can even exploit that security hole by placing the
 "right value" into place by a preceeding call.)
 
 ****************************************************************
@@ -386,7 +391,7 @@
 > guaranteed to always be initialized. No buts, ifs, and whens, or special
 > cases or corners that I need to check for after all.
 
-But do we achieve that by the above?  
+But do we achieve that by the above?
 Here is an example:
 
 procedure Test_Out_Param with SPARK_Mode is
@@ -405,10 +410,10 @@
    P (My_Neg (Y));
 end Test_Out_Param;
 
-With the change proposed in this AI, I get that after a call to P, Y 
+With the change proposed in this AI, I get that after a call to P, Y
 indeed is still properly initialized. But what about inside P? Certainly
-X is not in the bounds of My_Neg, and the fact that its initial value is set 
-by the default of some other type or not does not change anything about 
+X is not in the bounds of My_Neg, and the fact that its initial value is set
+by the default of some other type or not does not change anything about
 that...
 
 ****************************************************************
@@ -416,10 +421,10 @@
 From: Tucker Taft
 Sent: Thursday, April 30, 2020  9:04 AM
 
-Being initialized, but out of range, and having a random uninitialized value, 
-are two different things.  A compiler cannot assume an OUT parameter is 
-initialized to an in-range value.  But if it has a default, it can assume it 
-is not a random bit pattern, so a constraint check, for example, will have a 
+Being initialized, but out of range, and having a random uninitialized value,
+are two different things.  A compiler cannot assume an OUT parameter is
+initialized to an in-range value.  But if it has a default, it can assume it
+is not a random bit pattern, so a constraint check, for example, will have a
 well-defined result.
 
 ****************************************************************
@@ -427,20 +432,20 @@
 From: Bob Duff
 Sent: Thursday, April 30, 2020  9:20 AM
 
-> To me, the foremost reason in favor of the AI is that I would like to 
-> rely on the fact that any variable with specified default_value is 
-> guaranteed to always be initialized. No buts, ifs, and whens, or 
+> To me, the foremost reason in favor of the AI is that I would like to
+> rely on the fact that any variable with specified default_value is
+> guaranteed to always be initialized. No buts, ifs, and whens, or
 > special cases or corners that I need to check for after all.
-> 
+>
 > Just like non-null types .... no buts, ifs, except whens....
 
 Right, that's the property this AI is trying to preserve.
 
-> And as to risk: a deinitialized Integer is almost as bad as a 
-> deinitialized access value. All I need to do is use it as index into 
-> an array, where matching subtype properties are statically established 
-> and hence the index check unnecessary. (I can even exploit that 
-> security hole by placing the "right value" into place by a preceeding 
+> And as to risk: a deinitialized Integer is almost as bad as a
+> deinitialized access value. All I need to do is use it as index into
+> an array, where matching subtype properties are statically established
+> and hence the index check unnecessary. (I can even exploit that
+> security hole by placing the "right value" into place by a preceeding
 > call.)
 
 True in Ada 83, but now it's a bounded error, so "A(I) := ..."
@@ -451,13 +456,13 @@
 From: Claire Dross
 Sent: Thursday, April 30, 2020  9:22 AM
 
-> Being initialized, but out of range, and having a random uninitialized 
-> value, are two different things.  A compiler cannot assume an OUT parameter 
-> is initialized to an in-range value.  But if it has a default, it can 
-> assume it is not a random bit pattern, so a constraint check, for example, 
+> Being initialized, but out of range, and having a random uninitialized
+> value, are two different things.  A compiler cannot assume an OUT parameter
+> is initialized to an in-range value.  But if it has a default, it can
+> assume it is not a random bit pattern, so a constraint check, for example,
 > will have a well-defined result.
 
-I must say the difference on integer types does not seem obvious to me. And 
+I must say the difference on integer types does not seem obvious to me. And
 the problem raised by Erhard seems to still occur?
 
 ****************************************************************
@@ -465,7 +470,7 @@
 From: Bob Duff
 Sent: Thursday, April 30, 2020  11:49 AM
 
-> I must say the difference on integer types does not seem obvious to 
+> I must say the difference on integer types does not seem obvious to
 > me. And the problem raised by Erhard seems to still occur?
 
 No, adding to your earlier example:
@@ -491,8 +496,8 @@
 The above is required to raise C_E rather than trash some memory location.
 GNAT does that correctly (at least for this example).
 
-The compiler is not allowed to eliminate checks based purely on the subtype's 
-range -- it must also prove that the value is valid. This was an Ada 95 
+The compiler is not allowed to eliminate checks based purely on the subtype's
+range -- it must also prove that the value is valid. This was an Ada 95
 change.
 
 ****************************************************************
@@ -525,7 +530,7 @@
 
 >Just like non-null types .... no buts, ifs, except whens....
 
-Actually, there is one "but" with null exclusions, one that I noticed working 
+Actually, there is one "but" with null exclusions, one that I noticed working
 on this AI:
 
     Ptr : Some_Ptr := null;
@@ -536,11 +541,11 @@
 
     P (Ptr);
 
-A null exclusion on an out parameter cannot be assumed to be true, since there 
-is no way to initialize it with a non-null value if the actual is in fact null 
-(as in this example). We surely don't want to be conjuring a junk object out 
-of the ether just so we can pass it on the possible chance that someone might 
-read it. And we don't want to be raising exceptions for passing a value that 
+A null exclusion on an out parameter cannot be assumed to be true, since there
+is no way to initialize it with a non-null value if the actual is in fact null
+(as in this example). We surely don't want to be conjuring a junk object out
+of the ether just so we can pass it on the possible chance that someone might
+read it. And we don't want to be raising exceptions for passing a value that
 probably never will be used.
 
 Which probably goes to show that there is no rule that has no exceptions. :-)
@@ -550,11 +555,11 @@
 From: Tucker Taft
 Sent: Thursday, April 30, 2020  2:16 PM
 
-For OUT parameters, you generally have to assume the constraints are *not* 
-satisfied on the way in.  The point about having a default value, as do all 
-access objects, is that you can presume it has a *well defined* value.  The 
-constraints on an "out" parameter are checked only on the way "out" so you 
-should interpret an out parameter as always being a completely unconstrained 
+For OUT parameters, you generally have to assume the constraints are *not*
+satisfied on the way in.  The point about having a default value, as do all
+access objects, is that you can presume it has a *well defined* value.  The
+constraints on an "out" parameter are checked only on the way "out" so you
+should interpret an out parameter as always being a completely unconstrained
 object initially, that has some constraints you had better satisfy before you
 do a return.
 
@@ -563,11 +568,11 @@
 From: Randy Brukardt
 Sent: Thursday, April 30, 2020  2:45 PM
 
-Right. But that means that whatever you can assume about every other object 
+Right. But that means that whatever you can assume about every other object
 in an Ada program does not apply to "out" parameters. (with the exception of
-the tag and accessibility checks that would be impossible to properly check 
+the tag and accessibility checks that would be impossible to properly check
 on a usage, the focus of AI12-0378-1, the split from AI12-0377-1 as requested
-yesterday). My point to Erhard's statement is that there is always a "but" 
+yesterday). My point to Erhard's statement is that there is always a "but"
 when it comes to "out" parameters.
 
 ****************************************************************
@@ -575,10 +580,10 @@
 From: Richard Wai
 Sent: Thursday, April 30, 2020  2:59 PM
 
-I always saw such null excluded out parameters as expressing a contract on 
+I always saw such null excluded out parameters as expressing a contract on
 the subprogram. So a null exclusion on an “out” parameter is a contract which
 states that the subprogram promises to set the parameter to something not null.
-Similarly if you had an out parameter of some constrained subtype, that’s a 
+Similarly if you had an out parameter of some constrained subtype, that’s a
 contract on the subprogram to produce a value of that subtype.
 
 I don’t see anything wrong with this:
@@ -593,8 +598,8 @@
 
 Next_Meeting (My_Busy_Day);
 
-The contract is that Next_Meeting should only give me a Workday. But I 
-shouldn’t be stopped from using a parameter of Day, especially if it is not 
+The contract is that Next_Meeting should only give me a Workday. But I
+shouldn’t be stopped from using a parameter of Day, especially if it is not
 already set to a value in the range of Workday..
 
 ****************************************************************
@@ -602,27 +607,27 @@
 From: Erhard Ploedereder
 Sent: Friday, May 1, 2020  8:10 AM
 
-Interesting ....  but maybe there was a bug in the example? The semantics 
+Interesting ....  but maybe there was a bug in the example? The semantics
 that you describe seems too be "in out" semantics.
 
 See --  for inserts and remarks ...
 
->> I must say the difference on integer types does not seem obvious to 
+>> I must say the difference on integer types does not seem obvious to
 >> me. And the problem raised by Erhard seems to still occur?
-> 
+>
 > No, adding to your earlier example:
-> 
+>
 > procedure Test_Out_Param with SPARK_Mode is
 >    type My_Neg is new Integer range Integer'First .. -1 with
 >      Default_Value => -1;
 >    type My_Pos is new Integer range 1 .. Integer'Last with
 >      Default_Value => 1;
-> 
+>
 >    A : array (My_Neg range -1 .. -1) of Integer := (others => 0);
 
 -- added another array
      B : array (My_Pos range 1 .. 1) of Integer := (others => 0);
-> 
+>
 >    procedure P (X : out My_Neg) is
 >    begin
 >       A (X) := 123; -- Constraint_Error raised here.
@@ -632,7 +637,7 @@
         B (X) := 123; -- has to raise Constraint_Error for B(-1)
 
 >    end P;
-> 
+>
 >    Y : My_Pos;
 > begin
 >    P (My_Neg (Y));
@@ -647,34 +652,34 @@
 From: Bob Duff
 Sent: Friday, May 1, 2020  10:28 AM
 
-> Interesting ....  but maybe there was a bug in the example? The 
+> Interesting ....  but maybe there was a bug in the example? The
 > semantics that you describe seems too be "in out" semantics.
 
 Right, 'out' parameters sometimes pass information IN, which is strange.
 
 > >       A (X) := 123; -- Constraint_Error raised here.
-> 
+>
 > -- I would have expected that the Default_Value -1 applies and A(-1)
 > -- is perfectly fine, but
 
-That's not an unreasonable expectation, but I guess that's not what language 
-designers decided.  The goal was "if it has a default, it can't get 
-deinitialized", and never mind if the default is outside the bounds of the 
+That's not an unreasonable expectation, but I guess that's not what language
+designers decided.  The goal was "if it has a default, it can't get
+deinitialized", and never mind if the default is outside the bounds of the
 subtype, as we see in these weird 'out' param cases.
 
 >         B (X) := 123; -- has to raise Constraint_Error for B(-1)
-> 
+>
 > >    end P;
 > >
 > >    Y : My_Pos;
 > > begin
 > >    P (My_Neg (Y));
-> 
+>
 > -- has to raise Constraint_Error on the way out, when X (=-1) gets
 > -- written to Y per copy semantics for scalars
 
-If it were assigned to -1 inside the procedure, then it would raise C_E on copy 
-back.  But if it's not assigned at all (which is a weird thing to do), then it 
+If it were assigned to -1 inside the procedure, then it would raise C_E on copy
+back.  But if it's not assigned at all (which is a weird thing to do), then it
 remains +1, which copies back without C_E.
 
 Not sure I would have designed it that way...
@@ -684,21 +689,21 @@
 From: Erhard Ploedereder
 Sent: Friday, May 1, 2020  11:16 AM
 
-> Right, 'out' parameters sometimes pass information IN, which is 
+> Right, 'out' parameters sometimes pass information IN, which is
 > strange.
 
-Well, yes, sometimes, but not the value in the scalar case with copy 
+Well, yes, sometimes, but not the value in the scalar case with copy
 semantics. My reading of the Manual says that the value is uninitialized
 in the absence of Default_Value (8.6.1 (15)), or initialized to a specfified
 Default_Value (8.6.1.(13)). There is no third case. In consequence, the final
 value is just that if X is not assigned to in the body.
 
-So, your expectation that "1" from Y arrives at X is not justified by 
-anything in the manual, or is it? And, if the actual value were always passed 
-in, the Default_Value on out parameters would never engage and hence be 
+So, your expectation that "1" from Y arrives at X is not justified by
+anything in the manual, or is it? And, if the actual value were always passed
+in, the Default_Value on out parameters would never engage and hence be
 utterly useless.
 
-It may be strange that it always engages for scalar outs, but I much prefer 
+It may be strange that it always engages for scalar outs, but I much prefer
 that to deinitialized variables despite an assertion to the contrary.
 
 ****************************************************************
@@ -712,23 +717,23 @@
 >Well, yes, sometimes, but not the value in the scalar case with copy
 >semantics.
 >My reading of the Manual says that the value is uninitialized in the
->absence of Default_Value (8.6.1 (15)), 
+>absence of Default_Value (8.6.1 (15)),
 
 You mean 6.4.1(15).
- 
+
 >or initialized to a specfified
 >Default_Value (8.6.1.(13)).
 
-6.4.1(13) is about access types (and is one the the rules we need to change 
-slightly). 
+6.4.1(13) is about access types (and is one the the rules we need to change
+slightly).
 
-6.4.1(13.1/4) is about types with Default_Value and it does not say that. 
-It says the value of the actual is passed it without any check. That's the 
+6.4.1(13.1/4) is about types with Default_Value and it does not say that.
+It says the value of the actual is passed it without any check. That's the
 semantics that Ichbiah picked for out parameters like access and composites.
 
-I suppose we *could* have done something different regardless (it was a 
-totally new feature), but it's getting rather late to change basic semantics 
-of an Ada 2012 feature. Especially to silently change the semantics of 
+I suppose we *could* have done something different regardless (it was a
+totally new feature), but it's getting rather late to change basic semantics
+of an Ada 2012 feature. Especially to silently change the semantics of
 existing, legal code -- that's the worst kind of incompatibility.
 
 >There is no third case. In consequence, the
@@ -747,10 +752,10 @@
 My reading of the Manual says that the value is uninitialized in the absence
 of Default_Value (6.4.1 (15)), or initialized to ... (6.4.1.(13.1/4)).
 
-But you are right. I imagined semantics that never existed. I didn't even read 
-the sentence to its conclusion because it was so obvious what the initial 
+But you are right. I imagined semantics that never existed. I didn't even read
+the sentence to its conclusion because it was so obvious what the initial
 value would be. It is hard to believe that the semantics of Default_Value for
-out parameters are so misleading -- the type says that the default initial 
+out parameters are so misleading -- the type says that the default initial
 value is 1, and then means that the initial value is taken from the actual.
 
 Ok. Case closed for me, since the RM is consistent albeit very surprising.
@@ -760,27 +765,27 @@
 From: Tucker Taft
 Sent: Saturday, May 2, 2020  7:46 AM
 
->To be honest, I agree with Claire. To not assign anything to an out 
->parameter is plain wrong so I don't see why we should go to a lot of trouble 
->to get it to return something sensible in certain circumstances. (A former 
+>To be honest, I agree with Claire. To not assign anything to an out
+>parameter is plain wrong so I don't see why we should go to a lot of trouble
+>to get it to return something sensible in certain circumstances. (A former
 >colleague used somewhat stronger language).
 
-I remember Bob Morgan used to say something like: "Just because it is 
+I remember Bob Morgan used to say something like: "Just because it is
 erroneous doesn't mean we should generate code that deletes the disk."
 
-The fact is that most programs contain code whose execution might result in 
-erroneous execution or produce a bounded error. 
+The fact is that most programs contain code whose execution might result in
+erroneous execution or produce a bounded error.
 
-We provide certain guarantees so that even though the code may be buggy, you 
-know the consequences are limited.  Ada's access types have always made the 
-guarantee that an access value is never complete junk.  When we introduced the 
-Default_Value aspect, our goal was to make the same guarantee, namely that a 
-value of a type with a Default_Value is never complete junk.  You may believe 
-that was a mistake, but we made it many years ago, and at this point, I think 
+We provide certain guarantees so that even though the code may be buggy, you
+know the consequences are limited.  Ada's access types have always made the
+guarantee that an access value is never complete junk.  When we introduced the
+Default_Value aspect, our goal was to make the same guarantee, namely that a
+value of a type with a Default_Value is never complete junk.  You may believe
+that was a mistake, but we made it many years ago, and at this point, I think
 we should not withdraw that guarantee.
 
-We have discovered a corner case with view conversions.  I don't think that 
-means we should say: the guarantee holds except in certain corner cases.  We 
+We have discovered a corner case with view conversions.  I don't think that
+means we should say: the guarantee holds except in certain corner cases.  We
 should come up with a reasonable rule for this corner case.
 
 ****************************************************************
@@ -807,12 +812,12 @@
 >
 >Next_Meeting (My_Busy_Day);
 >
->The contract is that Next_Meeting should only give me a Workday. But I 
->shouldn’t be stopped from using a parameter of Day, especially if it is not 
+>The contract is that Next_Meeting should only give me a Workday. But I
+>shouldn’t be stopped from using a parameter of Day, especially if it is not
 >already set to a value in the range of Workday..
 
-What is more dubious is that nothing prevents me from not setting On_Day to a 
-Workday in Next_Meeting, and so, even if day has a default value. 
+What is more dubious is that nothing prevents me from not setting On_Day to a
+Workday in Next_Meeting, and so, even if day has a default value.
 
 ****************************************************************