CVS difference for ai05s/ai05-0005-1.txt

--- ai05s/ai05-0005-1.txt	2007/01/23 05:35:41	1.6
+++ ai05s/ai05-0005-1.txt	2007/02/20 23:31:19	1.7
@@ -182,6 +182,62 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Monday, January 22, 2007   8:53 PM
+
+The mail on AI05-0037 says (on the topic of whether <> needs to be added to any
+existing aggregate wording):
+
+4.3.3(23) worried me a bit, but I concluded it is already OK. <> means the
+component "initialized by default". If there are multiple associated components,
+each one will be initialized by default (and if that means that each component
+ends up with a different value, so be it). It doesn't say that one component
+is initialized by default, and then others are copied from it.
+
+4.3.1(20) also appears worrisome. But here it doesn't make sense to talk
+about "for each associated component" in the case of <>, because we're
+considering the value of <> for each individual associated component. (see
+4.3.1(19.1/2)). And each component has its own default expression or its own
+default initialization. After all, even the types of the components can be
+different for a single association.
+
+It might make sense to add an AARM note to make that point clear (for both
+4.3.1(20) and 4.3.3(23)), but I don't think any wording changes are needed.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 16, 2007  10:53 PM
+
+AC-0140 says that improved AARM notes are needed in 3.10.2(3), 3.10.2(29), and
+13.10(3). Here are those notes:
+
+3.10.2(3): Discussion: The Unchecked_Access attribute acts as if the object was
+declared at library-level; this applies even when it is used as the value of 
+anonymous access type. See 13.10.
+
+3.10.2(12.1): Ramification: If the value for this rule and the next one is derived
+from an Unchecked_Access attribute, the accessibility is library-level no matter
+what the accessibility level of the object is (see 13.10).
+
+3.10.2(13): Ramification: If the value of the actual is derived from an
+Unchecked_Access attribute, the accessibility is always library-level (see 13.10).
+
+13.10(3): Ramification: We say "rules and semantics" here so that library-level
+accessibility applies to the value created by X'Unchecked_Access as well as to
+the checks needed for the attribute itself. This means that any anonymous access
+values that inherit the accessibility of this attribute (such as access
+parameters) also act as if they have library-level accessibility. We don't want
+the "real" accessibility of the created value re-emerging at a later point -
+that would create hard-to-understand bugs.
+
+****************************************************************
+
+Editor's note (February 16, 2007): All of the items above this
+marker have been included in the working version of the AARM.
+
+****************************************************************
+
 From: Robert A. Duff
 Sent: Friday, January 19, 2007   3:43 PM
 
@@ -261,26 +317,3 @@
 
 ****************************************************************
 
-From: Randy Brukardt
-Sent: Monday, January 22, 2007   8:53 PM
-
-The mail on AI05-0037 says (on the topic of whether <> needs to be added to any
-existing aggregate wording):
-
-4.3.3(23) worried me a bit, but I concluded it is already OK. <> means the
-component "initialized by default". If there are multiple associated components,
-each one will be initialized by default (and if that means that each component
-ends up with a different value, so be it). It doesn't say that one component
-is initialized by default, and then others are copied from it.
-
-4.3.1(20) also appears worrisome. But here it doesn't make sense to talk
-about "for each associated component" in the case of <>, because we're
-considering the value of <> for each individual associated component. (see
-4.3.1(19.1/2)). And each component has its own default expression or its own
-default initialization. After all, even the types of the components can be
-different for a single association.
-
-It might make sense to add an AARM note to make that point clear (for both
-4.3.1(20) and 4.3.3(23)), but I don't think any wording changes are needed.
-
-****************************************************************