CVS difference for 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
@@ -10,7 +11,7 @@
-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
@@ -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
@@ -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