CVS difference for ai05s/ai05-0151-1.txt

Differences between 1.9 and version 1.10
Log of other versions for file ai05s/ai05-0151-1.txt

--- ai05s/ai05-0151-1.txt	2010/08/10 23:15:39	1.9
+++ ai05s/ai05-0151-1.txt	2010/10/19 03:51:17	1.10
@@ -1,9 +1,9 @@
-!standard  3.10.1(8/2)                             10-06-09    AI05-0151-1/07
+!standard  3.10.1(8/2)                             10-10-15    AI05-0151-1/08
 !standard  3.10.1(8.2/2)
 !standard  3.10.1(9.1/2)
 !standard  3.10.1(9.2/2)
 !standard  3.10.1(10/2)
-!standard  3.10.1(13/2)
+!standard  3.10.1(13)
 !class Amendment 09-04-29
 !status Amendment 2012 10-08-10
 !status ARG Approved 10-0-0  10-06-19
@@ -17,7 +17,7 @@
 
 !summary
 
-Make limited views of packages more useful by allowing more use
+Limited views of packages are made more useful by allowing more uses
 of the incomplete types they make visible.
 
 !problem
@@ -48,7 +48,7 @@
 
 !wording
 
-Revise 3.10.1(5/2 - 10/2):
+Revise 3.10.1(5/2 - 10/2) [as modified by AI05-0098-1]:
 
   A name that denotes an incomplete view of a type may be used as follows:
 
@@ -135,14 +135,14 @@
 the parameter passing mechanism from the access-to-subprogram type.
 
 Note that we have chosen to allow incomplete types as function results,
-even though we restricted tagged incomplete types to being parameters
-only. This seems inconsistent. Why should tagged incomplete types be
-*more* restrictive than incomplete types in general? Well, they
-shouldn't be, so with this proposal, the only advantage a tagged
-incomplete type will have is that a call or body *will* be permitted on
-a subprogram with tagged incomplete parameters, provided they are not
-controlling parameters. Tagged or untagged incomplete types will be
-permitted as both parameters and results when declaring a subprogram.
+even though Ada 2005 restricted tagged incomplete types to being parameters
+only. Therefore this proposal extends the abilities of tagged incomplete types
+as well as untagged incomplete types. Thus, with this proposal, the only
+advantage a tagged incomplete type will have is that a call or body *will*
+be permitted on a subprogram with tagged incomplete parameters, provided
+they are not controlling parameters. Tagged or untagged incomplete types
+will be permitted as both parameters and results when declaring a
+subprogram.
 
 The net effect of this proposal is that changing a "with" to a "limited with"
 will be much less of a disruption for a client package, since it may continue
@@ -197,7 +197,7 @@
 having a formal parameter of an untagged incomplete view,
 nor a return type that is an incomplete view.
 
-!corrigendum 3.10.1(13/2)
+!corrigendum 3.10.1(13)
 
 @dinsa
 @xindent<@s9<85  Within a @fa<declarative_part>, an @fa<incomplete_type_declaration>

Questions? Ask the ACAA Technical Agent