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

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0005-1.txt

--- ai05s/ai05-0005-1.txt	2007/01/13 05:25:56	1.4
+++ ai05s/ai05-0005-1.txt	2007/01/19 04:00:06	1.5
@@ -146,3 +146,38 @@
 have occurred. Thus this rule is not incompatible with Ada 95.
+From: Randy Brukardt
+Sent: Tuesday, January 16, 2007   5:53 PM
+The rules 4.3(3/2), 4.3.1(8/2), 4.3.2(4/2), and 4.3.3(7/2) can be confusing.
+These are the rules that determine how an aggregate is resolved.
+Tucker says (privately) that these rules are "additive"; 4.3(3/2) says don't
+look inside an aggregate until you have a single array, record, or record
+extension type. 4.3.1(8/2) says that you don't start
+considering the "record aggregate" possibility until you
+have a single record or record extension type. And so on.
+There should be AARM notes that explain this on 4.3(3/2) and 4.3.2(4/2). (There
+are already notes on 4.3.1(8/2) and 4.3.3(7/2).
+After 4.3(3/2), we should have something like:
+AARM Ramification: There are additional rules for each kind of aggregate. These
+aggregate rules are additive; a legal expression needs to satisfy all of the
+applicable rules. That means the rule given here must be satisfied even when
+it is syntactally possible to tell which specific kind of aggregate is being
+After 4.3.2(4/2), we should have something like:
+AARM Ramification: This rule is additive with the rule given in 4.3. That means
+that rule must be satisfied even though it is alway syntactally possible to
+tell that something is an extension aggregate. Specifically, that means that
+an extension aggregate is ambiguous if the context is overloaded on array and/or
+record types, even though those are never legal contexts for an extension
+aggregate. Thus, this rule acts more like a legality rule than a name resolution

Questions? Ask the ACAA Technical Agent