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

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0376-1.txt

--- ai12s/ai12-0376-1.txt	2020/04/22 00:27:48	1.1
+++ ai12s/ai12-0376-1.txt	2020/05/02 03:43:14	1.2
@@ -1,5 +1,7 @@
-!standard 13.1(10/4)                                  20-04-17  AI12-0376-1/01
+!standard 13.1(10/4)                                  20-04-30  AI12-0376-1/02
 !class Amendment 20-04-17
+!status Amendment 1-2012 20-04-30
+!status ARG Approved 14-0-0  20-04-29
 !status work item 20-04-17
 !status received 20-03-31
 !priority Low
@@ -34,8 +36,8 @@
 with:
 
 It is illegal to specify a nonconfirming type-related representation aspect 
-for an untagged by-reference type if it is derived from a by-reference type,
-or if one or more types have been derived from it prior to the specification 
+for an untagged by-reference type T if it is derived from a by-reference type,
+or if one or more types have been derived from T prior to the specification 
 of the aspect.
 
 !discussion
@@ -44,10 +46,10 @@
 practical to change the representation as noted in AI95-0246-1. Thus, the
 by-reference part of the rule is needed.
 
-However, the part about primitive subprogram is essentially a methodological
+However, the part about primitive subprograms is essentially a methodological
 restriction. If the conversion is between two types with the same value set
 but different representations, there is no semantic problem. The main purpose
-here is to prevent expensive implementation conversions.
+here is to prevent expensive implicit conversions.
 
 Methodological restrictions are always questionable, as they merely prevent a
 programmer from doing something that they may actually need to do. After all,
@@ -141,8 +143,8 @@
 by-reference type after one or more types have been derived from it.
 @dby
 It is illegal to specify a nonconfirming type-related representation aspect 
-for an untagged by-reference type if it is derived from a by-reference type,
-or if one or more types have been derived from it prior to the specification 
+for an untagged by-reference type @i<T> if it is derived from a by-reference type,
+or if one or more types have been derived from @i<T> prior to the specification 
 of the aspect.
 
 !ASIS
@@ -365,7 +367,10 @@
 > types, even when they have user-defined primitives, as specified in 
 > 13.1(10).
 
-You've said that you believe that there are only two kinds of type-related aspects, and I don't think that Default_Component_Value makes much sense as an operational aspect. (Do we want to allow Default_Component_Value on a partial view?? I think not.) Be
sides...
+You've said that you believe that there are only two kinds of type-related 
+aspects, and I don't think that Default_Component_Value makes much sense as
+an operational aspect. (Do we want to allow Default_Component_Value on a 
+partial view?? I think not.) Besides...
  
 > It also may be time to consider eliminating the 
 > user-defined-primitive-related restriction part of 13.1(10).

Questions? Ask the ACAA Technical Agent