CVS difference for ais/ai-00168.txt

Differences between 1.13 and version 1.14
Log of other versions for file ais/ai-00168.txt

--- ais/ai-00168.txt	2000/04/14 01:45:08	1.13
+++ ais/ai-00168.txt	2000/07/15 02:30:00	1.14
@@ -1,4 +1,4 @@
-!standard 04.06    (12)                               00-04-11  AI95-00168/07
+!standard 04.06    (12)                               00-07-13  AI95-00168/08
 !standard 03.07.01 (07)
 !class binding interpretation 96-11-16
 !status Corrigendum 2000 99-07-27
@@ -61,13 +61,13 @@
 
 !wording
 
-Add the following clause after RM95 4.6(12):
+Add the following clause after 4.6(12):
 
 In a view conversion for an array type, the target type and the operand type
 shall either both have aliased components, or both have non-aliased
 components.
 
-Add the following sentence at the end of RM95 3.7.1(7):
+Add the following sentence at the end of 3.7.1(7):
 
 However, in the case of a general access subtype, a discriminant_constraint is
 illegal if there are places within the immediate scope of the designated
@@ -80,7 +80,7 @@
 with non-aliased components.  Such a conversion must be disallowed.
 
 The ARG also discussed the following example, which illustrates another case
-where the RM seems to allow a discriminant to be changed:
+where the standard seems to allow a discriminant to be changed:
 
   with Q;
   package body P is
@@ -96,7 +96,7 @@
 
 "if a component_definition contains the reserved word aliased and the type of
 the component is discriminated, then the nominal subtype of the component
-shall be constrained." (RM95 3.6(11))
+shall be constrained." (3.6(11))
 
 Also note that the problem exists with non-private types, provided that the
 characteristic that the type is unconstrained is not visible everywhere:
@@ -111,10 +111,10 @@
 on the assignment to Q.X, but that would be very expensive.  Moreover, a
 compile-time check would clearly be better than a run-time check.
 
-Aliased-ness of the components is not really what is causing trouble, though.
+Aliasedness of the components is not really what is causing trouble, though.
 It is really the existence of a general access type, and in fact of a
 discriminant constraint on such an access type, which causes trouble.  Thus,
-forbidding such a constraint seems like the right solution, especially
+forbidding such a constraint is the chosen solution, especially
 considering that constraints on access types are not a terribly useful
 feature.
 

Questions? Ask the ACAA Technical Agent