CVS difference for ai12s/ai12-0416-1.txt

--- ai12s/ai12-0416-1.txt	2021/01/09 08:02:16	1.2
+++ ai12s/ai12-0416-1.txt	2021/01/15 04:27:50	1.3
@@ -1,4 +1,6 @@
-!standard 5.5(9/5)                                   21-01-08  AI12-0416-1/04
+!standard 5.5(9/5)                                   21-01-14  AI12-0416-1/05
+!standard 6.1.2(17/5)
+!standard 6.4(7)
 !standard 6.4(9)
 !standard 6.4(10.1/2)
 !standard A.18(2/5)                            
@@ -20,6 +22,16 @@
 (3) Add a sentence explaining when a parallel construct with a 
 loop_parameter_specification is complete.
 
+(4) The equivalence of a call on a prefixed view with a normal call is
+also true statically, so that the same Legality Rules are enforced on 
+the prefix as would be enforced on a normal call.
+
+(5) Assertion expressions that apply to a call are included in the Global
+aspect even when the expressions are not enabled.
+
+(6) The rule about named associations following any positional associations
+applies only to a single actual_parameter_part.
+
 !problem
 
 (1) The term "container type" is used in A.18(12/5). But the only definition
@@ -42,10 +54,24 @@
 (4) 6.4(10.1/2) [a Dynamic Semantics paragraph] says that a prefixed view
 is equivalent to a call on the underlying subprogram. Equivalences defined
 in Dynamic Semantics only apply to runtime (not Legality). There are a number
-of Legality Rules that apply to calls. Two Legality Rules in 4.1.3 cover two
+of Legality Rules that apply to calls, and in particular to parameters of 
+calls, which need to be enforced on prefixed views (and in particular the
+prefix of a prefixed view). Two Legality Rules in 4.1.3 cover two
 important cases, but there don't appear to be any language that would, for
-instance, make calling an abstract subprogram via a prefixed view illegal.
+instance, apply the anti-order dependence rules of 6.4.1 to the prefix of
+a prefixed view as if it is a parameter.
 
+(5) 6.1.2(17/5) includes "including any assertion expressions that might be 
+evaluated as part of the call, including preconditions, postconditions, 
+predicates, and type invariants." Does this include assertion expressions
+that are not enabled? One can read it either way.
+
+(6) 6.4(7) includes "Any positional associations shall precede any named 
+associations." This could be read to include nested calls. But we want
+a call like:
+        Func1 (Param1 => True, Param_2 => Func2 (123))
+to be legal.
+
 !proposal
 
 (1) Rewrite the basic introductory paragraph to clarify the meaning of
@@ -59,6 +85,12 @@
 
 (4) Move 6.4(10.1/2) to Static Semantics (after 6.4(9)).
 
+(5) Add "(even if not enabled)" to 6.1.2(17/5) and make other improvements
+to the wording.
+
+(6) Prefix the rule with: "For the parameter_associations of a single actual_parameter_part
+or iterator_actual_parameter_part,".
+
 !wording
 
 [Editor's note: These changes were applied to Draft 28 of the Ada 202x RM, 
@@ -111,6 +143,22 @@
 
 (4) Move 6.4(10.1/2) after 6.4(9), under the heading "Static Semantics".
 
+(5) Modify 6.1.2(17/5):
+
+  The Global aspect for a callable entity defines the global variables that 
+  might be referenced as part of a call on the entity, including any assertion
+  expressions that [might be evaluated as part of]{apply to} the call{ (even 
+  if not enabled)}, including preconditions, postconditions, predicates, and 
+  type invariants.
+
+(6) Modify 6.4(7):
+
+A parameter_association is named or positional according to whether or not the 
+formal_parameter_selector_name is specified. {For the parameter_associations 
+of a single actual_parameter_part or iterator_actual_parameter_part, any}[Any]
+positional associations shall 
+precede any named associations. Named associations are not allowed if the prefix
+in a subprogram call is an attribute_reference. 
 
 !discussion
 
@@ -160,9 +208,18 @@
 In particular, rules that apply to actual parameters have to apply to the
 prefix of a prefixed view. It isn't practical to copy all of those into
 4.1.3.
+
+The first rule (and any rule that depends only on the subprogram's properties)
+is covered by the sentence in 4.1.3(9.2/3): "The selected_component denotes a 
+view of this subprogram that omits the first formal parameter." But this does
+not cover any rule that applies to the actual parameter of a call (since the
+prefix is not defined to be such a parameter).
+
+The equivalence in 6.4(10.1/2) covers runtime rules, but it doesn't apply
+at compile-time (as noted in the question).
 
-Instead we change the equivalence to Static Semantics, which makes it apply
-to Legality Rules as well as runtime semantics.
+In order to make that equivalence apply at compile time, we need to change
+the equivalence to Static Semantics.
 
 Note that the Legality Rules 4.1.3(13.1/5) and 4.1.3(13.2/2) are NOT
 redundant. They apply not just to calls, but also to uses of a prefixed view
@@ -182,6 +239,27 @@
 No simple fix seems available for this particular issue, which is why we chose
 to ignore it at this point.]
 
+(5) We try to avoid having Legality Rules depend on whether an assertion is
+enabled. That prevents the act of enabling an assertion from changing the 
+legality of a program unit.
+
+The "might" in the original wording was intended to convey that, but it is
+clearly not enough to make that point. So we explicitly mention that assertion
+expressions that are "not enabled" are included.
+
+(6) We need to clarify that we are talking only about a single list of 
+parameters. Otherwise, the rule could be interpreted textually. We have
+fixed the wording of a number of other rules over the years that have
+similar nesting problems (for instance, the naming of subtypes in 
+access-to-subprogram types are not the subtypes associated directly
+with conformance of a parameter list). Now that it has been noted, this one
+should be fixed, too.
+
+Note that iterator_actual_parameter_part also uses parameter_associations,
+so this rule also applies to them and we want that to remain the case.
+Generic instantiations has their own rule for this; it doesn't need a fix
+since instances cannot be nested.
+
 !corrigendum 5.5(9/4)
 
 @drepl
@@ -241,6 +319,27 @@
 the total number of iterations of the loop represents an upper bound
 on the number of logical threads of control devoted to the loop.
 
+!corrigendum 6.1.2(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum 6.4(7)
+
+@drepl
+A @fa<parameter_association> is @i<named> or @i<positional> according to 
+whether or not the @i<formal_parameter_>@fa<selector_name> is specified.
+Any positional associations shall precede any named associations. Named 
+associations are not allowed if the @fa<prefix> in a subprogram call is 
+an @fa<attribute_reference>. 
+@dby
+A @fa<parameter_association> is @i<named> or @i<positional> according to 
+whether or not the @i<formal_parameter_>@fa<selector_name> is specified.
+For the @fa<parameter_association>s of a single @fa<actual_parameter_part>
+or @fa<iterator_actual_parameter_part>, any positional associations shall
+precede any named associations. Named associations are not allowed if the
+@fa<prefix> in a subprogram call is an @fa<attribute_reference>. 
+
 !corrigendum 6.4(9)
 
 @dinsa
@@ -404,5 +503,47 @@
 Still waiting for thoughts. :-)
 
 I haven't written this up yet, as I don't know the solution to use.
+
+****************************************************************
+
+From the AARM review of Steve Baird, October 2020
+
+In 6.1.2(17/5) we talk about assertion expressions. Interactions with
+assertion policy need to be clarified.
+
+****************************************************************
+
+Editor's response to the above (January 2021)
+
+Clearly, we don't want Legality to change when something is enabled or 
+disabled, so I'd suggest adding "even if they are disabled".
+
+Tucker suggests rewording as:
+
+   ... defines the global variables that might be referenced as part of a
+   call on the entity, including any assertion expressions that [might be 
+   evaluated as part of]{apply to} the call{ (even if not enabled)}, 
+   including preconditions, postconditions, predicates, and type invariants.
+
+****************************************************************
+
+From the AARM review of Steve Baird, October 2020
+
+I suppose we *could* clarify that the rule 6.4(7):
+       Any positional associations shall precede any named associations.
+applies separately to each actual_parameter_part. For example, the
+following function call is legal:
+     Func1 (Param1 => True, Param_2 => Func2 (123))
+even though a positional association "follows" a named association.
+
+****************************************************************
+
+Editor's response to the above (January 2021)
+
+This actually bothers me enough to worry about it. We've generally fixed such
+issues when they've been noted, for instance for subtypes in subprogram 
+declarations. We probably should prefix this rule with "For the 
+parameter_associations of a single actual_parameter_part or 
+iterator_actual_parameter_part,".
 
 ****************************************************************