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

Differences between 1.21 and version 1.22
Log of other versions for file ai12s/ai12-0005-1.txt

--- ai12s/ai12-0005-1.txt	2016/12/28 04:20:38	1.21
+++ ai12s/ai12-0005-1.txt	2017/06/06 01:45:44	1.22
@@ -929,7 +929,86 @@
 
 ***************************************************************
 
-Editor's note (December 15, 2016): All of the items above this
+From: Tucker Taft
+Sent: Tuesday, May 2, 2017  11:52 AM
+
+I bumped into the following when looking for cases where dynamic accessibility
+checks occur.  The rule for array type conversion talks about access
+parameters, but I don't see how they are relevant to this issue:
+
+In section 4.6, in the dynamic semantics for Array Type Conversion:
+
+39.1/2
+{AI95-00392-01} If the component types of the array types are anonymous access
+types, then a check is made that the accessibility level of the operand type
+is not deeper than that of the target type.
+
+39.b/2
+Reason: This check is needed for operands that are access parameters and in
+instance bodies. Other cases are handled by the legality rule given previously.
+
+---
+
+I would suggest we drop the mention of access parameters here.  Since the
+designated type of the access parameter is necessarily a named type, even when
+converting X.all where X is "access Array_Of_Anon_Acc" you know the level of
+the components of Array_Of_Anon_Acc.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, May 11, 2017  12:10 AM
+
+> I bumped into the following when looking for cases where dynamic 
+> accessibility checks occur.
+
+Careful: you might convince me to issue more ACATS tests on that. ;-)
+
+> The rule for array type
+> conversion talks about access parameters, but I don't see how they are 
+> relevant to this issue:
+
+You mean the AARM note, obviously not normative.
+
+> In section 4.6, in the dynamic semantics for Array Type Conversion:
+> 
+> 39.1/2
+> {AI95-00392-01} If the component types of the array types are 
+> anonymous access types, then a check is made that the accessibility 
+> level of the operand type is not deeper than that of the target type.
+> 
+> 39.b/2
+> Reason: This check is needed for operands that are access parameters 
+> and in instance bodies. Other cases are handled by the legality rule 
+> given previously.
+>
+> ---
+> 
+> I would suggest we drop the mention of access parameters here.  Since 
+> the designated type of the access parameter is necessarily a named 
+> type, even when converting X.all where X is "access Array_Of_Anon_Acc" 
+> you know the level of the components of Array_Of_Anon_Acc.
+
+I tried to figure out where this particular note came from, but it doesn't
+seem to be mentioned anywhere. So it's possible I just copied it from the
+access version 4.6(48.a), without enough thought.
+
+Assuming that Mr. Baird agrees with this change (he can find ways to cause
+issues that defy the rest of us!), I'll just make it (like other AARM note
+changes, those do not go on the agenda or get discussed at the ARG level).
+[Steve, I'd like a positive answer that you agree with Tuck.]
+
+***************************************************************
+
+From: Steve Baird
+Sent: Thursday, May 11, 2017  8:44 AM
+
+> Assuming that Mr. Baird agrees with this change...
+I agree with Tuck.
+
+***************************************************************
+
+Editor's note (June 5, 2017): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent