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

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0236-1.txt

--- ai12s/ai12-0236-1.txt	2019/01/18 05:09:54	1.8
+++ ai12s/ai12-0236-1.txt	2019/01/22 06:07:53	1.9
@@ -1,6 +1,7 @@
-!standard 2.8(6)                                      19-01-17  AI12-0236-1/07
+!standard 2.8(6)                                      19-01-21  AI12-0236-1/08
 !standard 3.9.2(3)
 !standard 3.10.2(9.1/3)
+!standard 3.10.2(16.1/3)
 !standard 3.10.2(32.2/3)
 !standard 4.3.2(5.4/3)
 !standard 4.3.3(15.1/3)
@@ -166,7 +167,7 @@
 Modify 2.8(6):
 
   * After a semicolon delimiter, but not within a formal_part{,}[ or]
-    discriminant_part{, or declare_expression.
+    discriminant_part{, or declare_expression}.
 
 Modify 3.9.2(3):
 
@@ -176,11 +177,11 @@
    statically by the operand's (specific) type, dynamically by its tag at 
    run time, or from context. A qualified_expression or parenthesized 
    expression is statically, dynamically, or indeterminately tagged according 
-   to its operand. {A declare_expression is statically, dynamically, or 
-   indeterminately tagged according to its *body*_expression. A 
-   conditional_expression is statically, dynamically, or indeterminately 
-   tagged according to rules given in 4.5.7.} For other kinds of 
-   names and expressions, this is determined as follows:
+   to its operand. {A conditional_expression is statically, dynamically, or 
+   indeterminately tagged according to rules given in 4.5.7. A 
+   declare_expression is statically, dynamically, or indeterminately tagged 
+   according to its *body*_expression. }For other kinds of names and 
+   expressions, this is determined as follows:
 
 [Editor's note: This looks like a complete list of exceptions from the usual
 rule, but we previously did not mention the special rules for 
@@ -191,9 +192,21 @@
     The accessibility level of a declare_expression (see 4.5.9) is
     the accessibility level of the *body*_expression.
 
+Modify 3.10.2(16.1/3):
+
+   In the above rules, the operand of a view conversion, parenthesized 
+   expression or qualified_expression is considered to be used in a context 
+   if the view conversion, parenthesized expression or qualified_expression 
+   itself is used in that context. Similarly, a dependent_expression of a 
+   conditional_expression is considered to be used in a context if the 
+   conditional_expression itself is used in that context{, and a 
+   *body_*expression of a declare_expression is considered to be used in a 
+   context if the declare_expression itself is used in that context}.
+
 Add to the definition of "distributed accessibility" after 3.10.2(32.2/3):
 
-   * a declare_expression (see 4.5.9); or
+   * a declare_expression (see 4.5.9) whose *body_*expression has distributed 
+     accessibility; or
 
 Add after 4.3.2(5.4/3), in the rule for extension aggregates:
 
@@ -231,12 +244,12 @@
 unless it is an aggregate, a function_call, a raise_expression, a 
 parenthesized expression or qualified_expression whose operand is permitted 
 by this rule, [or] a conditional_expression all of whose dependent_expressions
-are permitted by this rule{, or a dependent_expression whose body_expression 
+are permitted by this rule{, or a declare_expression whose body_expression 
 is permitted by this rule}: 
 
 Add after 8.1(3):
 
-    - a declare_expression
+    - a declare_expression;
 
 [Editor's note: This adds it to the list of constructs that have a
 declarative region. This, together with 8.2(2) means that the immediate
@@ -292,6 +305,102 @@
               Stream.Cur_Position = Old_Pos + 1
               and then Result = Character'Pos (The_Char)));
 
+!corrigendum 2.8(6)
+
+@drepl
+@xbullet<After a semicolon delimiter, but not within a @fa<formal_part> or
+@fa<discriminant_part>.>
+@dby
+@xbullet<After a semicolon delimiter, but not within a @fa<formal_part>,
+@fa<discriminant_part>, or @fa<declare_expression>.>
+
+!corrigendum 3.9.2(3)
+
+@drepl
+A @fa<name> or expression of a tagged type is either @i<statically> tagged, 
+@i<dynamically> tagged, or @i<tag indeterminate>, according to whether, when 
+used as a controlling operand, the tag that controls dispatching is determined 
+statically by the operand's (specific) type, dynamically by its tag at 
+run time, or from context. A @fa<qualified_expression> or parenthesized 
+expression is statically, dynamically, or indeterminately tagged according 
+to its operand. For other kinds of @fa<name>s and 
+expressions, this is determined as follows:
+@dby
+A @fa<name> or expression of a tagged type is either @i<statically> tagged, 
+@i<dynamically> tagged, or @i<tag indeterminate>, according to whether, when 
+used as a controlling operand, the tag that controls dispatching is determined 
+statically by the operand's (specific) type, dynamically by its tag at 
+run time, or from context. A @fa<qualified_expression> or parenthesized 
+expression is statically, dynamically, or indeterminately tagged according 
+to its operand. A @fa<conditional_expression> is statically, dynamically, or 
+indeterminately tagged according to rules given in 4.5.7. A 
+@fa<declare_expression> is statically, dynamically, or indeterminately tagged 
+according to its @i<body_>@fa<expression>. For other kinds of @fa<name>s and 
+expressions, this is determined as follows:
+
+!corrigendum 3.10.2(9.1/3)
+
+@dinsa
+@xbullet<The accessibility level of a @fa<conditional_expression> (see 4.5.7) 
+is the accessibility level of the evaluated @i<dependent_>@fa<expression>.>
+@dinst
+@xbullet<The accessibility level of a @fa<declare_expression> (see 4.5.9) is
+the accessibility level of the @i<body_>@fa<expression>.>
+
+!corrigendum 3.10.2(16.1/3)
+
+@drepl
+In the above rules, the operand of a view conversion, parenthesized expression or
+@fa<qualified_expression> is considered to be used in a context if the view conversion,
+parenthesized expression or @fa<qualified_expression> itself is used in that context.
+Similarly, a @i<dependent_>@fa<expression> of a @fa<conditional_expression> is
+considered to be used in a context if the @fa<conditional_expression> itself is
+used in that context.
+@dby
+In the above rules, the operand of a view conversion, parenthesized expression or
+@fa<qualified_expression> is considered to be used in a context if the view conversion,
+parenthesized expression or @fa<qualified_expression> itself is used in that context.
+Similarly, a @i<dependent_>@fa<expression> of a @fa<conditional_expression> is
+considered to be used in a context if the @fa<conditional_expression> itself is
+used in that context, and a @i<body_>@fa<expression> of a @fa<declare_expression>
+is considered to be used in a context if the @fa<declare_expression> itself is used 
+in that context.
+
+!corrigendum 3.10.2(32.2/3)
+
+@dinsa
+@xbullet<a @fa<conditional_expression> (see 4.5.7); or>
+@dinst
+@xbullet<a @fa<declare_expression> (see 4.5.9) whose @i<body_>@fa<expression> 
+has distributed accessibility; or>
+
+!corrigendum 4.3.2(5.4/3)
+
+@drepl
+@xbullet<a @fa<conditional_expression> having at least one 
+@i<dependent_>@fa<expression> that would violate this rule.>
+@dby
+@xbullet<a @fa<conditional_expression> (see 4.5.7) having at least one 
+@i<dependent_>@fa<expression> that would violate this rule; nor>
+
+@xbullet<a @fa<declare_expression> (see 4.5.9) whose @i<body_>@fa<expression>
+would violate this rule.>
+
+!corrigendum 4.3.3(15.1/3)
+
+@drepl
+@xbullet<For a @fa<conditional_expression>, the applicable index constraint 
+for each @i<dependent_>@fa<expression> is that, if any, defined for the 
+@fa<conditional_expression>.>
+@dby
+@xbullet<For a @fa<conditional_expression> (see 4.5.7), the applicable index 
+constraint for each @i<dependent_>@fa<expression> is that, if any, defined for 
+the @fa<conditional_expression>;>
+
+@xbullet<For a @fa<declare_expression> (see 4.5.9), the applicable index 
+constraint for the @i<body_>@fa<expression> is that, if any, defined for the 
+@fa<declare_expression>.>
+
 !corrigendum 4.4(7/3)
 
 @drepl
@@ -373,6 +482,53 @@
       @b<not> Tampering_With_Cursors_Prohibited (Result) @b<and then>
       Result.Capacity @>= Length)>
 
+!corrigendum 6.2(10/4)
+
+@drepl
+A parameter of a by-reference type is passed by reference, as is an explicitly
+aliased parameter of any type. Each value of a by-reference type has an associated
+object. For a parenthesized expression, @fa<qualified_expression>,
+or view conversion, this object is the one associated with the
+operand. For a value conversion, the associated object is the anonymous result
+object if such an object is created (see 4.6); otherwise it is the
+associated object of the operand. For a @fa<conditional_expression>, this object
+is the one associated with the evaluated @i<dependent_>@fa<expression>.
+@dby
+A parameter of a by-reference type is passed by reference, as is an explicitly
+aliased parameter of any type. Each value of a by-reference type has an associated
+object. For a parenthesized expression, @fa<qualified_expression>,
+or view conversion, this object is the one associated with the
+operand. For a value conversion, the associated object is the anonymous result
+object if such an object is created (see 4.6); otherwise it is the
+associated object of the operand. For a @fa<conditional_expression>, this object
+is the one associated with the evaluated @i<dependent_>@fa<expression>.
+For a @fa<declare_expression>, this object is the one associated with the
+@i<body_>@fa<expression>.
+
+!corrigendum 7.5(2.1/5)
+
+@drepl
+In the following contexts, an @fa<expression> of a limited type is not permitted
+unless it is an @fa<aggregate>, a @fa<function_call>, a @fa<raise_expression>,
+a parenthesized @fa<expression> or @fa<qualified_expression> whose operand is
+permitted by this rule, or a @fa<conditional_expression> all of whose
+@i<dependent_>@fa<expression>s are permitted by this rule:
+@dby
+In the following contexts, an @fa<expression> of a limited type is not permitted
+unless it is an @fa<aggregate>, a @fa<function_call>, a @fa<raise_expression>,
+a parenthesized @fa<expression> or @fa<qualified_expression> whose operand is
+permitted by this rule, a @fa<conditional_expression> all of whose
+@i<dependent_>@fa<expression>s are permitted by this rule, or a 
+@fa<declare_expression> whose @i<body_>@fa<expression> is permitted by this 
+rule:
+
+!corrigendum 8.1(3)
+
+@dinsa
+@xbullet<a @fa<block_statement>;>
+@dinst
+@xbullet<a @fa<declare_expression>;>
+
 !ASIS
 
 New ASIS queries are needed. Those are TBD.
@@ -3918,6 +4074,74 @@
 
 Just think, the introduction of declare_expressions will give us many new ways 
 to fail accessibility checks. The ACATS tester in me can't wait. ;-)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 21, 2019  11:45 PM
+
+I've finally gotten back to adding the rest of AI12-0236-1 to the draft 
+Standard. I don't think any of these are controversial, but since these all 
+but the last two go beyond editorial, I'm asking if anyone has an objections
+to any of these suggestions. Note that all of these will be in the AI that 
+we'll see at our next meeting; hopefully, we can avoid much discussion on this 
+but there are too many changes to treat them all as editorial.
+
+P.S. Starting at (12) since that is where I left off last time. Anyone that 
+thinks that it is easy to add a feature to Ada should look at the number of 
+issues that this one has generated (*after* we thought it was done).
+
+--------
+
+(12) Add after 3.10.2(32.2/3):
+
+ * a declare_expression (see 4.5.9); or
+
+...which adds this to "distributed accessibility". However, 3.10.2(32.5/3) 
+assumes that every distributed accessibility expression has a 
+conditional_expression in it somewhere.
+
+We could try to fix 3.10.2(32.5/3), but the purpose of this stuff is to deal 
+with the fact that we don't know the accessibility of a conditional expression
+statically, since we don't know which branch will be executed.
+That is not a problem with a declare_expression, the rules make it clear that 
+the accessibility is that of the *body_*expression.
+
+That means the reason for including declare_expression here is to deal with 
+the case of a declare_expression with a nested conditional_expression:
+    (declare A : Ptr := ...
+     begin (if B > 10 then A else C'access));
+
+So we don't want *any* declare_expression here, but just the ones that have 
+conditional_expressions as their body expression. So we should use wording 
+that echoes that for qualified expressions:
+
+* a declare_expression (see 4.5.9) whose *body_*expression has distributed 
+  accessibility; or
+
+(13) 3.10.2(16.1/3) includes rules for both qualified expressions and 
+conditional expressions, but doesn't have a similar rule for 
+declare_expression. This would matter when the body_expression of a 
+declare_expression is a function call, for instance:
+    P := Ptr(Func); -- The result has the accessibility of Ptr, whatever that is.
+but without 16.1,
+    P := Ptr(declare A ... begin Func); -- The result has the accessibility of 
+        -- the expression, probably will fail an accessibility check.
+
+I think this might have been omitted when a declare expression was itself a 
+master, but now that that isn't true, I think we need declare_expression in 
+3.10.2(16.1/3). Probably:
+
+In the above rules, the operand of a view conversion, parenthesized expression 
+or qualified_expression is considered to be used in a context if the view 
+conversion, parenthesized expression or qualified_expression itself is used 
+in that context. Similarly, a dependent_expression of a conditional_expression 
+is considered to be used in a context if the conditional_expression itself is 
+used in that context{, and a body_expression of a declare_expression is 
+considered to be used in a context if the declare_expression itself is used in 
+that context}.
+
+P.S. I'm done with this AI now, I think. Only 9 more giant AIs to go...
 
 ***************************************************************
 

Questions? Ask the ACAA Technical Agent