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

--- ai12s/ai12-0378-1.txt	2020/09/02 03:55:24	1.8
+++ ai12s/ai12-0378-1.txt	2020/09/11 22:23:10	1.9
@@ -2,6 +2,7 @@
 !standard 6.4.1(18/3)
 !class Binding Interpretation 20-06-18
 !status Amendment 1-2012 20-07-07
+!status ARG Approved 12-1-1  20-09-09
 !status work item 20-04-29
 !status received 20-03-26
 !priority Low
@@ -17,8 +18,8 @@
 !question
 
 The legality rule that prevents view conversions of unrelated access
-types for out parameters is a compatibility problem in practice. When we
-implemented this in GNAT, a significant number of tests in our customer
+types for out parameters is a compatibility problem in practice. When AdaCore
+implemented this in GNAT, a significant number of tests in their customer
 regression test suite failed to compile. Should we handle such view
 conversions in a more compatible way? (Yes.)
 
@@ -76,10 +77,11 @@
 
   Corrigendum: Added rules to ensure that the value passed into a{n} out
   parameter for {scalar}[elementary] types is well-defined in the case of
-  a view conversion. The new rules can be incompatible. For a view conversion
-  to an unrelated type with the Default_Value aspect specified, the
-  aspect is new in Ada 2012 so it should be unlikely to occur in
-  existing code.[ For a view conversion to an unrelated access type, the
+  a view conversion. The new rules can be incompatible. {View conversions from/}
+  [For a view conversion ]to an unrelated type with the Default_Value aspect
+  specified[,] { are unlikely to occur in existing code, as} the
+  aspect is new in Ada 2012[ so it should be unlikely to occur in
+  existing code]. [For a view conversion to an unrelated access type, the
   incompatibility is possible as this could be written in Ada 95, but such
   a view conversion is thought to be rare. In both cases, ]{D}eclaring and
   passing a temporary rather than a view conversion will eliminate the problem.
@@ -164,7 +166,7 @@
 
 We could have required null to be passed for all out parameters of
 access types. That might have been a more sensible rule for a new
-language, but the runtime incompatibility creating by generally making
+language, but the runtime incompatibility created by generally making
 such a change would be intolerable, so it is much too late to
 contemplate that.
 
@@ -730,5 +732,44 @@
 for any such conversion, even one that has no semantic effect.) But once we
 start making some sort of check, it's probably easier to include constraints
 in it -- those are rare anyway.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Wednesday, September 9, 2020  10:04 AM
+
+Sorry, but I missed mentioning this editorial comment for AI12-0378-1
+
+Corrigendum  (just befor Discussion)
+
+"For a view conversion to an unrelated type with the Default_Value aspect 
+specified, the aspect is new in Ada 2012 so it should be unlikely to occur in
+existing code."
+
+This sentence is weird.
+
+Suggest.
+
+"View conversions to an unrelated type with the Default_Value aspect 
+specified, are unlikely to occur in existing code, since the aspect is new 
+in Ada 2012."
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April 29, 2020  4:05 PM
+
+...
+> Suggest.
+> 
+> "View conversions to an unrelated type with the Default_Value aspect 
+> specified, are unlikely to occur in existing code, since the aspect is 
+> new in Ada 2012."
+
+I don't think the first comma in this replacement ought to be there. That is,
+
+   "View conversions to an unrelated type with the Default_Value 
+   aspect specified are unlikely to occur in existing code, 
+   since the aspect is new in Ada 2012."
 
 ****************************************************************