CVS difference for ai05s/ai05-0144-2.txt

--- ai05s/ai05-0144-2.txt	2010/06/14 01:24:50	1.11
+++ ai05s/ai05-0144-2.txt	2010/08/13 05:32:36	1.12
@@ -1,7 +1,8 @@
-!standard 6.04.01 (6)                                 10-06-02  AI05-0144-2/07
+!standard 6.04.01 (6)                                 10-07-09  AI05-0144-2/08
 !standard 6.0.5(5.8/3)
 !class Amendment 09-06-07
 !status Amendment 2012 10-04-23
+!status ARG Approved  9-0-0  10-06-20
 !status work item 10-05-20
 !status ARG Approved  5-0-4  10-02-26
 !status work item 09-06-07
@@ -64,20 +65,19 @@
 
   * one of the two names statically denotes a renaming declaration
     whose renamed object_name is known to denote the same object
-    as the other, and every index expression for each
-    indexed_component which occurs within the renamed
-    object_name is a known to be unvarying expression, and the dereferenced
-    name for each (implicit or explicit) dereference which
-    occurs within the renamed object_name is a known to be unvarying name.
+    as the other, the prefix of any dereference within the renamed
+    object_name is not a variable, and any expression within the renamed
+    object_name contains no references to variables nor 
+    calls on non-static functions.
 
 AARM Reason: This exposes known renamings of slices, indexing, and so on
 to this definition. In particular, if we have
    C : Character renames S(1);
 then C and S(1) are known to denote the same object.
 
-We need the requirement for dereferences and index expressions to be
-"known to be unvarying" in renames in order to avoid problems from later changes
-to those parts of renamed names. Consider:
+We need the requirement that no variables occur in the prefixes of dereferences
+and in (index) expressions of the renamed object in order to avoid problems
+from later changes to those parts of renamed names. Consider:
 
       type Ref is access Some_Type;
       Ptr : Ref := new Some_Type'(...);
@@ -88,13 +88,37 @@
 
 X and Ptr.all should not be known to denote the same object, since they denote
 different allocated objects (and this is not an unreasonable thing to do).
-
-We don't need a similar requirement for slices as the existing requirement for
-statically matching index constraints eliminates any problems (the index
-constraints either have to be static or declared by the same subtype declaration).
 End AARM Reason.
 
+AARM To Be Honest: The exclusion of variables from renamed object_names is not enough to
+prevent altering the value of the name or expression by another access path. For instance,
+both *in* parameters passed by reference and access-to-constant values can designate
+variables. For the intended use of "known to be the same object", this is OK; the modification
+via another access path is very tricky and it is OK to reject code that would be buggy
+except for the tricky code. For example:
+
+     Global : Tagged_Type;
 
+     procedure Foo (Param : in Tagged_Type := Global) is
+         X : Element renames Some_Global_Array (Param.C);
+     begin
+         Global.C := Global.C + 1;
+         Swap (X, Some_Global_Array (Param.C));
+
+The rules will flag the call of procedure Swap as illegal, since X and
+Some_Global_Array (Parameter.C) are known to denote the same object (even though they will
+actually represent different objects if Param = Global). But this is only incorrect if the
+parameter actually is Global and not some other value; the error could exist for some calls.
+So this flagging seems harmless.
+
+Similar examples can be constructed using stand-alone composite constants with controlled
+or immutably limited components, and (as previously noted) with dereferences of
+access-to-constant values. Even when these examples flag a call incorrectly, that call depends
+on very tricky code (modifying the value of a constant); the code is likely
+to confuse future maintainers as well and thus we do not mind rejecting it.
+End AARM To Be Honest.
+
+
     AARM Discussion: Whether or not names or prefixes are known to denote the
     same object is determined statically. If the name contains some dynamic
     portion other than a dereference, indexed_component, or
@@ -121,57 +145,6 @@
 
 
 
-A name or expression is *known to be unvarying* if it denotes:
- * a static expression; or
- * a constant object; or
-
-AARM Discussion: This covers constant object_declarations, generic formal *in* objects, 
-   constant extended return objects, and exception choice parameters.
-
- * a loop parameter; or
- * a non-aliased formal parameter of mode *in*; or
-[Editor's note: "non-aliased" assuming that AI-142-4 is approved.]
- * a selected_component of a known to be unvarying name.
-
-AARM Ramification: Dereferences, indexed_components, and slices are never known to be
-unvarying even if the prefix is known to be unvarying. It is important that be true for
-a dereference of an access-to-constant, as such an access may designate a variable object.
-We could have included indexed_components with all index expressions being known to be
-unvarying, but it doesn't seem important for the usage and we can always add more rules
-if we are letting too many obvious cases slip through.
-
-AARM To Be Honest: The inclusion of selected components and composite *in* parameters
-means that it might be possible to alter the value of the name or expression by another
-access path. For the use that we are putting this term to, this is OK; the modification
-via another access path is very tricky and it is OK to reject code that would be buggy
-except for the tricky code. For example:
-
-     Global : Tagged_Type;
-
-     procedure Foo (Param : in Tagged_Type := Global) is
-         X : Element renames Some_Global_Array (Param.C);
-     begin
-         Global.C := Global.C + 1;
-         Swap (X, Some_Global_Array (Param.C));
-
-The rules will flag procedure Swap as illegal, since X and Some_Global_Array (Parameter.C)
-are known to denote the same object (even though they will actually represent different objects
-if Param = Global). But this is only incorrect if the parameter actually is Global and not
-some other value; the error could exist for some calls. So this flagging seems harmless.
-
-Similar examples can be constructed using stand-alone composite constants with controlled
-or immutably limited components.
-End AARM To Be Honest.
-
-[Editor's note: We used "known to be unvarying" here as terms using forms of "constant"
-seemed to be misleading ("constant" has a meaning in Ada and this is slightly different).
-For instance, the first term used was "known constant value" which was intended to be read
-"(known constant) value", but it could also be read "known (constant value)" which seems to
-imply that the value is known, not just that the value is a constant. "known constant name"
-and "known constant expression" have similar issues. And all of these engender confusion
-with the meaning of "constant" as defined in 3.3.1.]
-
-
 Two names are *known to refer to the same object* if
 
      The two names are known to denote the same object; or
@@ -253,7 +226,7 @@
 to fail.
 
 
-[Editor's note: In defining "known to be unvarying", it was noticed that the wording
+[Editor's note: In one of the eariler drafts of this AI, it was noticed that the wording
 for extended_return_statements defines it to be a full constant declaration, but fails
 to define the object as a constant object. The other three cases all explicitly define
 themselves to be constant objects (that never happens by default). We correct that here.]
@@ -573,18 +546,11 @@
 index constraints; or>
 
 @xbullet<one of the two @fa<name>s statically denotes a renaming declaration
-whose renamed @i<object_>@fa<name> is known to denote the same object as the other,
-and every index @fa<expression> for each @fa<indexed_component> which occurs
-within the renamed @i<object_>@fa<name> is a known to be unvarying @fa<expression>,
-and the dereferenced @fa<name> for each (implicit or explicit) dereference which
-occurs within the renamed @i<object_>@fa<name> is a known to be unvarying @fa<name>.>
-
-A @fa<name> or @fa<expression> is @i<known to be unvarying> if it denotes:
-@xbullet<a static @fa<expression>; or>
-@xbullet<a constant object; or>
-@xbullet<a loop parameter; or>
-@xbullet<a non-aliased formal parameter of mode @b<in>; or>
-@xbullet<a @fa<selected_component> of a known to be unvarying @fa<name>.>
+whose renamed @i<object_>@fa<name> is known to denote the same object as the
+other, the @fa<prefix> of any dereference within the renamed
+@i<object_>@fa<name> is not a variable, and any @fa<expression> within the
+renamed @i<object_>@fa<name> contains no references to variables nor 
+calls on non-static functions.>
 
 Two @fa<name>s are @i<known to refer to the same object> if: