CVS difference for ais/ai-00295.txt

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

--- ais/ai-00295.txt	2002/06/12 00:36:46	1.3
+++ ais/ai-00295.txt	2002/10/01 03:08:54	1.4
@@ -1,5 +1,9 @@
-!standard  3.07.01 (7/1)                               02-05-16  AI95-00295/01
+!standard  3.07.01 (7/1)                               02-09-27  AI95-00295/02
+!standard  3.06 (11)
+!standard  3.06 (22/1)
+!standard  3.08 (18/1)
 !class binding interpretation 02-05-16
+!status work item 02-09-27
 !status received 02-05-16
 !qualifier Error
 !priority Medium
@@ -8,6 +12,10 @@
 
 !summary
 
+3.6(11) is enforced in the private part of instances. There is a check
+on component_definitions in instance bodies that 3.6(11) is not violated;
+if it is violated, Program_Error is raised.
+
 !question
 
 The following illustrates a case of access subtype
@@ -57,22 +65,100 @@
      null;
    end Foo;
 
-The solution typically used in cases like these (i.e. impose an
-"assume the worst in a generic body" rule) seems very restrictive
-in this case. Rejecting the declaration of Foo.G.A on the grounds
-that its aliased component's subtype might turn out to be unconstrained
-seems extreme. Should this case be checked for at runtime, as part of
-the elaboration of the component subtype? I do not see an obvious
-solution.
-
 !recommendation
 
+(See summary.)
+
 !wording
 
+Add at the end of 3.6(11):
+    In addition to the places where Legality Rules normally apply
+    (see 12.3), this rule applies also in the private part of an instance
+    of a generic unit.
+
+Replace 3.6(22/1)
+    The elaboration of a component_definition in an array_type_definition
+    consists of the elaboration of the subtype_indication.
+with
+    The elaboration of a component_definition with the reserved word ALIASED
+    includes a check that the component subtype is either undiscriminated
+    or constrained. The exception Program_Error is raised if this check fails
+    (this can only occur in an instance body - see 3.6(11)).
+    The elaboration of a component_definition in an array_type_definition
+    consists of this check and the elaboration of the subtype_indication,
+    in an arbitrary order.
+
+Add at the end of 3.8(18/1)
+    The elaboration of a component_definition with the reserved word ALIASED
+    also includes the check, described in 3.6, that the component subtype
+    is either undiscriminated or constrained. The elaboration of a
+    component_definition in a record_type_definition consists of this check and
+    the actions described in this subclause, in an arbitrary order.
+
 !discussion
 
+Three solutions to this problem were considered:
+
+An assume-the-worst rule. The idea is to adjust 3.6(11) to disallow
+"aliased T" in a component_definition in a generic body if T might be
+discriminated with defaults. We would require that 3.6(11) be enforced in
+the private part of a generic instance.
+
+This is a classic assume-the-worst rule, and it would be simple and
+consistent with the rest of the language. However, it would be unacceptably
+restrictive and incompatible with existing code.
+
+It would require rejection of the following example:
+
+    generic
+        type T is private;
+    package G is
+        ...
+    end G;
+
+    package body G is
+        type R is
+           record
+              F : aliased T;
+              ...
+           end record;
+        ...
+    end G;
+
+Thus, this alternative was rejected.
+
+
+A second alternative is much more radical. The basic idea is to disallow
+(constrained) access subtypes for general access types. 3.6(11) would be
+eliminated.
+
+This would eliminate the root cause of the problem. Indeed, we could
+repeal 3.3.1(9) as well, making it possible to add or remove the aliased
+keyword without semantic effects.
+
+However, this would be incompatible with existing code, IF code exists
+which actually uses this feature. (This is somewhat questionable.)
+
+This argument was rendered moot when it was noted that such a prohibition
+would be a contract model violation for generic formal access types (which
+can be either general or pool-specific).
+
+We could fix the contract problem with a run-time legality check or an
+assume-the-worst check. But that only worsens the compatibility concern.
+
+An alternative solution would be to disallow (constrained) access subtypes for
+all access types. But, as that feature goes back to Ada 83, it seems likely to
+cause excessive compatibility problems.
+
+
+The third alternative is to adopt a run-time check similar to the accessibility
+check. This is ugly at best, but doesn't have any fatal flaws. So this choice
+was adopted.
+
 !ACATS test
 
+A C-Test should be constructed to check that this rule is enforced.
+
 !appendix
 
 From: Steve Baird
@@ -354,7 +440,7 @@
 
 ****************************************************************
 
-From: Steve Baird
+From: Tucker Taft
 Sent: Thursday, May 16, 2002  3:36 PM
 
 > The same does not hold for the "check some (but not all)
@@ -760,6 +846,145 @@
 there are significant uses of the feature such that there would be a lot of
 opposition to the change, I'd rather spend the time on something productive
 (like my resume :-).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, September 9, 2002  5:06 PM
+
+The Minutes of the June 2002 (Vienna) ARG meeting mention
+three possible solutions to the problem described in AI-295:
+
+     1) An "assume the worst" rule in generic bodies.
+     2) A new runtime check.
+     3) Make general access subtypes illegal.
+
+ #1 -
+     To recap, this is Tuck's description of this approach (taken from the AI):
+       Adjust 3.6(11) to disallow "aliased T" in a component_definition
+       in a generic body if T might be discriminated with defaults.  (The
+       "assume the worst" model would suggest this.)  We would require that
+       3.6(11) be enforced in the private part of a generic instance.
+
+     This would be, in some sense, the cleanest, most consistent solution to
+     the problem. It would be straightforward to define and easy to implement.
+
+     I believe that it would be unacceptably restrictive.
+
+     It would require rejection of the following example:
+
+         generic
+            type T is private;
+         package G is
+             ...
+         end G;
+
+         package body G is
+             type R is
+               record
+                 F : aliased T;
+                 ...
+               end record;
+             ...
+          end G;
+
+     I feel that this would be a bad idea even if compatibility were not
+     a concern; compatibility considerations reenforce this position.
+
+     In my opinion, no further discussion of this approach is needed.
+
+ #2 -
+     To recap, this is my description of this approach (taken from the AI):
+       Program_Error is raised during the elaboration of a
+       an aliased comonent_definition if the component subtype
+       is unconstrained and discriminated.
+
+       3.6(11)'s prohibition of "bad" aliased components ought to
+       extend into the private parts of instances.
+
+     There is general agreement with Tuck's point that checking at runtime
+     for a construct which is statically forbidden outside of an instance
+     body is "pretty distasteful". On the other hand, accessibility
+     checking is already defined in this way.
+
+ #3 -
+     To recap, this is Tuck's description of this approach (taken from the AI):
+         Disallow (constrained) access subtypes for general access types.
+
+     It appeared at first that there were no significant language
+     definition issues with this approach; the only important question
+     seemed to be whether this restriction was too incompatible.
+
+     However, the Vienna minutes conclude with:
+
+         After the meeting, Tucker and Randy discussed this, and Tuck realized
+         that this would be a contract model violation on formal access types
+         (which can match both pool-specific and general access types).
+         So option 3 is out.
+
+Thus, options #1 and #3 are fatally flawed, while #2 is only ugly; I
+advocate #2.
+
+ The following is proposed RM wording for proposal #2:
+
+     Add at the end of 3.6(11):
+         In addition to the places where Legality Rules normally apply
+         (see 12.3), this rule applies also in the private part of an instance
+         of a generic unit.
+
+     Replace 3.6(22/1)
+         The elaboration of a component_definition in an array_type_definition
+         consists of the elaboration of the subtype_indication.
+     with
+         The elaboration of a component_definition with the reserved word ALIASED
+         includes a check that the component subtype is either undiscriminated
+         or constrained. The exception Program_Error is raised if this check fails
+         (this can only occur in an instance body - see 3.6(11)).
+         The elaboration of a component_definition in an array_type_definition
+         consists of this check and the elaboration of the subtype_indication,
+         in an arbitrary order. The elaboration of a component_definition in a
+         record_type_definition consists of this check and the actions described
+         in 3.8, in an arbitrary order.
+
+     Add at the end of 3.8(18/1)
+         The elaboration of a component_definition with the reserved word ALIASED
+         also includes the check, described in 3.6, that the component subtype
+         is either undiscriminated or constrained.
+
+ I'm not very happy with this wording, but the other alternatives that came to
+ mind all involved even more extensive overriding of one section of the RM
+ by another (e.g. a rule like "In addition to what is stated elsewhere,
+ the elaboration of a component_definition with the reserved word ALIASED
+ also includes a check that ... ").
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, September 27, 2002
+
+One possible improvement would be to avoid trying to have a single
+definition of the check. It doesn't seem long enough to bother with that.
+Moreover, I'd make the 3.8(18) part a separate paragraph - 3.8(18/1) is way
+too long already. So perhaps something like the following would be better:
+
+Replace 3.6(22/1)
+     The elaboration of a component_definition in an array_type_definition
+     consists of the elaboration of the subtype_indication.
+with
+     The elaboration of a component_definition in an array_type_definition
+     consists of the elaboration of the subtype_indication and a check that
+     the component subtype is either undiscriminated or constrained if the
+     component_definition includes the reserved keyword ALIASED, in an
+     arbitrary order. The exception Program_Error is raised if this check
+     fails (this can only occur in an instance body - see 3.6(11)).
+
+Add as a new paragraph after 3.8(18/1)
+     The elaboration of a component_definition in a record_type_definition
+     consists of the actions described elsewhere in this subclause and a check
+     that the component subtype is either undiscriminated or constrained if the
+     component_definition contains the reserved keyword ALIASED, in an
+     arbitrary order. The exception Program_Error is raised if this check
+     fails (this can only occur in an instance body - see 3.6(11)).
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent