CVS difference for ais/ai-00363.txt

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

--- ais/ai-00363.txt	2004/04/30 02:35:39	1.4
+++ ais/ai-00363.txt	2004/06/08 01:04:53	1.5
@@ -1,4 +1,4 @@
-!standard  03.07(08/1)                                  04-02-28  AI95-00363/02
+!standard  03.07(08/1)                                  04-06-05  AI95-00363/03
 !class amendment 03-11-26
 !status work item 03-11-26
 !status received 03-11-15
@@ -8,7 +8,10 @@
 
 !summary
 
-Those ^&**^$% access subtypes gotta go.
+Disallow access subtypes for general access types that have defaults
+for their discriminants, or for any access type that completes
+a private view that has no discriminants. Allow for unconstrained
+heap objects when the private view has no discriminants.
 
 !problem
 
@@ -49,94 +52,113 @@
 
 !proposal
 
+Part 1:
+
 Disallow the discriminant constraint on a general
 access type if the discriminants have defaults on the
 designated type, recheck in an instance and presume the worst
 in a generic body.
 
-We must disallow constraints on *all* access types
-declared outside the package defining the private type (presuming the
-private view has no visible discriminants), allocating
-space for unconstrained objects in the heap even when
-constraints are given in the allocator for such an access type,
-and setting the 'Constrained attribute False when dereferencing
-values of such an access type.
+Part 2:
 
-If the access type is a general access type, then this "new" semantics for
-allocators should apply to access types declared inside the package
-as well, presuming the designated subtype is not constrained,
-since subtypes would be disallowed on the "inside" general access types
-as well. Furthermore, there would need to be rules disallowing
-a 'Access that delivers a value of such a type being applied to a
-constrained variable (3.10.2(27)), and disallowing conversion from some other
-access type that had constrained designated objects (4.6(16)).
-Both 3.10.2(27) and 4.6(16) would then say "discriminated and indefinite"
-rather than "discriminated and unconstrained."
+For a private type with no visible discriminants, completed
+by a discriminated type with defaults, allow heap objects to
+be unconstrained. For such types, we must disallow both
+general and pool-specific access subtypes. The 'Constrained
+attribute would be False when dereferencing values of such an access type.
+There would need to be rules disallowing a 'Access that delivers a
+value of such a type being applied to a constrained variable (3.10.2(27)),
+and disallowing conversion from some other access type that had constrained
+designated objects (4.6(16)). Essentially the requirement for statically
+matching designated subtypes would carry over if there is a partial
+view that is not visibly unconstrained.
 
 !wording
 
-Modify 3.3.1(9):
+[part 1] Drop AI-295 -- it was strictly related to access subtype concerns.
 
-    ... or the object is constant or [aliased (see 3.10)] {limited} the actual subtype ...
-    [In the case of an aliased object, this initial value may be explicit or
-    implicit; in the other cases, an explicit initial value is required.] ...
+[part 1] Drop AI-275
 
-Delete 3.6(11).
+NOTE: The change proposed by AI-275 to 12.5.3(8) is no longer justified
+based on concerns about constrained access subtypes. However, the change
+might still be justified if we were concerned about the effect on optimizers
+if an array with aliased components were "viewed" as an array without aliased
+components, or vice-versa.  However, this is only a concern in the presence of
+shared generics, and in that case, this is a probably a negligible extra
+overhead. Hence, we recommend that AI-275 be dropped, and the changes
+associated with AI-168 (which are already in RM2000) be "backed out."
 
-Replace the second sentence of 3.7.1(7/1) with:
+[part 1] Modify 3.3.1(9):
 
-    ... However, in the case of a general access subtype, a discriminant_constraint
-    is illegal if the designated type has defaults for its discriminants. In addition
-    to the places where Legality Rules normally apply (see 12.3), these rules apply
-    also in the private part of an instance of a generic unit. In a generic body,
-    this rule is checked presuming a formal access type of the generic might be a
-    general access type, and a non-tagged discriminated formal type of the generic might
-    have defaults.
+    ... or the object is constant [or aliased (see 3.10)] the actual subtype ...
+    [In the case of an aliased object, this initial value may be explicit or
+    implicit; in the other cases, an explicit initial value is required.] ...
 
-NOTE: The change proposed by AI-275 to 12.5.3(8) is no longer justified
-based on concerns about constrained access subtypes. However, the change
-might still be justified if we are concerned about an array with aliased
-components being "viewed" as an array without aliased components, or vice-versa.
-In the presence of optimization, this could be a legitimate concern, so AI-275
-should be reevaluated in the light of that concern, rather than access subtype
-concerns. If AI-275 is dropped, then perhaps the changes associated with
-AI-168 (which are already in RM2000) should be "backed out."
+[part 1] Delete 3.6(11).
+
+[part 1, augmenting AI-168] Replace the second sentence of 3.7.1(7/1) with:
 
-Drop AI-295 -- it was strictly related to access subtype concerns.
+    ... However, in the case of a general access subtype, a
+    discriminant_constraint is illegal if the designated type has defaults for
+    its discriminants. In addition to the places where Legality Rules normally
+    apply (see 12.3), these rules apply also in the private part of an instance
+    of a generic unit. In a generic body, this rule is checked presuming all
+    formal access types of the generic might be general access types, and all
+    non-tagged discriminated formal types of the generic might have defaults.
 
-In 3.10(9), delete the last two sentences (starting with
+[part 1] In 3.10(9), delete the last two sentences (starting with
 "If the view defined by an object_declaration is aliased...").
 
-Modify 3.10.2(26):
+[part 1] Modify 3.10.2(26):
 
     ... unless this subtype is indefinite, or the variable is [aliased]
     {constrained by its initial value}.
+[part 2] Replace last part of 3.10.2(27) with:
+
+    ... if D is untagged, then the type of the view shall be D, and either:
+       - A's designated subtype shall statically match the nominal subtype
+         of the view; or
+       - D shall be discriminated in its full view and unconstrained in any
+         partial view, and A's designated subtype shall be unconstrained.
+
+[part 1, relaxing AI-168] Replace 4.6(12.1/1) with:
+
+    * In a view conversion, if the target type has aliased components, then
+      so shall the operand type.
+
+[part 2] Replace 4.6(16) with:
 
-Modify 3.10.2(27):
-    ... if D is untagged, then the type of the view shall be D, and A's
-    designated subtype shall either statically match the nominal subtype of
-    the view or be discriminated and [unconstrained] {indefinite};
-
-Modify 4.6(16):
-    ... or the target designated subtype shall be discriminated and
-    [unconstrained] {indefinite}; and
+    * If the target designated type is not tagged, then the designated
+      types shall be the same, and either:
+        - the designated subtypes shall statically match; or
+        - the designated type shall be discriminated in its full view and
+          unconstrained in any partial view, and the target designated
+          subtype shall be unconstrained.
 
-Modify 4.8(6):
+[part 2] Replace 4.8(6) with:
 
     If the designated type of the allocator is elementary, then the subtype
     of the created object is the designated subtype. If the designated type
-    is composite, then the created object is [always constrained;]
-    {unconstrained if and only if:
+    is composite, then the subtype of the created object is the designated
+    subtype when the designated subtype is constrained or there is a partial
+    view of the designated type that is constrained; otherwise, the
+    created object is constrained by its initial value (even if the designated
+    subtype is unconstrained with defaults).
+
+  AARM NOTE: The created object is effectively contrained by its initial
+    value if the access type is an access-to-constant type, or the
+    designated type is limited (in all views), but we don't need to
+    state that here. It is implicit in other rules. Note, however,
+    that a value of an access-to-constant type can designate a variable
+    object via 'Access or conversion, and the variable object might
+    be assigned by some other access path, and that assignment might
+    alter the discriminants.
 
-       * the access type is an access-to-variable type; and
-       * the full view of the designated subtype is nonlimited and unconstrained; and
-       * there is a partial view of the designated subtype that is constrained.
-
-    Otherwise, the created object is constrained;} if the {full view of the}
-    designated subtype is constrained, then it provides the constraint;
-    otherwise the object is constrained by its initial value
-    (even if the designated subtype is unconstrained with defaults).
+[part 1] Modify 8.5.1(5/1):
 
+    ... unless this subtype is indefinite, or the variable is [aliased]
+    {constrained by its initial value}. ...
+
 !discussion
 
 Allowing constrained access subtypes of general access types has created
@@ -557,5 +579,31 @@
 problem: you'd prefer this to be the default case. Of course, with more
 incompatibility, we could make this the default, and then use the attribute
 to force back to the old way if there is trouble.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, June 5, 2004 11:48 AM
+
+Here is a new version of AI-363 having to do with
+access subtypes. [Editor's note: This is version /03.] I have identified
+each wording change as either "part 1" or "part 2" where
+part 1 is eliminating general access subtypes, while
+part 2 relates to private types completed with
+discriminated-with-defaults full types.
+
+I recommend we do both.  I have been careful to make part 2
+as compatible as possible.  Essentially what it does is
+require static matching of designated subtypes for 'Access
+and conversions for access-to-private when the private
+type has no visible discriminants, even if the full view does
+have discriminants.  This allows objects of such a private
+type to be unconstrained in the heap.  By part 1, such
+objects would already be unconstrained if declared "aliased."
+
+I think this will fix some nasty privacy breakages in the
+language, as well as simplify it overall.  Adding "aliased"
+to a declaration will now have many fewer subtle semantic
+and legality effects.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent