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,".
****************************************************************
Questions? Ask the ACAA Technical Agent