CVS difference for ais/ai-00225.txt

Differences between 1.4 and version 1.5
Log of other versions for file ais/ai-00225.txt

--- ais/ai-00225.txt	2001/10/19 01:36:44	1.4
+++ ais/ai-00225.txt	2002/05/25 03:42:18	1.5
@@ -1,6 +1,7 @@
-!standard 3.10     (09)                              01-10-17  AI95-00225/02
+!standard 3.10     (09)                              02-05-14  AI95-00225/03
 !class binding interpretation 99-12-09
-!status ARG approved 8-0-0  01-10-07
+!status Amendment 200Y 02-05-14
+!status ARG Approved 8-0-0  01-10-07
 !status work item 99-12-09
 !status received 99-12-09
 !qualifier Clarification
@@ -10,7 +11,7 @@
 
 !summary
 
-The current instance of a type is aliased if:
+The current instance of a type is aliased if and only:
    The type is tagged and limited; or
    The type has the reserved word limited in its full definition.
 
@@ -18,7 +19,7 @@
 
 The attributes Access and Unchecked_Access are allowed only on aliased
 objects, "including possibly the current instance of a limited type within
-its definition", in the words of the standard.
+its definition", in the words of the standard (3.10.2(24/1)).
 
 But the standard never says where the type is limited. There are types that
 can become nonlimited later in their immediate scope, because the full type
@@ -53,7 +54,7 @@
 type to become non-limited later (if a component type becomes non-limited, for
 instance). So this is not sufficient, some checking still has to be deferred.
 
-The difficulty of making the check begs the question as to whether this
+The difficulty of making the check raises the question as to whether this
 complex check is helpful to Ada users. Since it is unclear if a type is
 limited, users may be confused as to whether 'Access is allowed. This is not
 helpful.
@@ -121,7 +122,7 @@
 the use of T'Access or T'Unchecked_Access inside the type, because
 only a limited type has an aliased "current instance."
 In my attempt to add an enforcement for this rule, I ran into
-a nasty situation.  When do you decide whether a type is truly "limited"?
+a nasty situation. When do you decide whether a type is truly "limited"?
 There are types that can become nonlimited later in their immediate scope,
 because the full type of a component turns out to be nonlimited.
 There are also cases where in a generic package a spec a type
@@ -132,7 +133,7 @@
 Ultimately, I implemented a bit of a half-baked check.
 When encountering the T'Access or T'Unchecked_Access during
 the initial processing of a record type, if the type *might*
-be limited then we allow it.  Later, when an individual object
+be limited then we allow it. Later, when an individual object
 is created which causes the T'Access or T'Unchecked_Access to
 be evaluated, if the type is not limited at that point, we complain.
 This is clearly less than desirable.
@@ -149,7 +150,7 @@
 not have seen all of the components (we haven't seen the ones that
 come later in the record than the one with the use of T'Access), and one of
 the components might turn out to be limited, rendering the whole
-record limited.  Of course, we could implement the check in a second
+record limited. Of course, we could implement the check in a second
 pass, or set a flag indicating that we saw a T'Access somewhere,
 but then as mentioned above, the limitedness might disappear later
 anyway.
@@ -157,9 +158,9 @@
 This all seems pretty unsavory, and makes me want to suggest
 that the rule should be that you may only use T'[Unchecked_]Access
 inside an untagged record type if it explicitly uses the
-word "limited" in its definition.  This has the nice characteristic
+word "limited" in its definition. This has the nice characteristic
 that only types that are return-by-reference have an aliased
-current instance.  That's good, because if they are not return-by-reference,
+current instance. That's good, because if they are not return-by-reference,
 (and not controlled), then the object is allowed to be copied and moved
 around as part of a function return, which would render the use
 of T'[Unchecked_]Access pretty meaningless.

Questions? Ask the ACAA Technical Agent