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

--- ai05s/ai05-0080-1.txt	2008/01/17 07:24:41	1.1
+++ ai05s/ai05-0080-1.txt	2008/03/07 06:15:19	1.2
@@ -1,5 +1,6 @@
-!standard 3.1(7)                                           08-01-16    AI05-0080-1/01
+!standard 3.1(7)                                           08-02-22    AI05-0080-1/02
 !class binding interpretation 08-01-16
+!status ARG Approved  7-0-1  08-02-10
 !status work item 08-01-16
 !status received 07-12-07
 !priority Low
@@ -16,7 +17,7 @@
 
 We often have arguments about whether "object" or "type" means exactly that,
 or whether it really means "view of an object" or "view of a type". It's
-generally agreed that the Standard would make any sense if this is not
+generally agreed that the Standard would not make any sense if this is not
 applied, because there are many places where a view is what is being considered
 (otherwise privacy would be broken).
 
@@ -30,23 +31,24 @@
 
 !recommendation
 
-(See Summary.)
+(See summary.)
 
 !wording
 
 Add after 3.1(7):
 
 When it is clear from context, the term *object* is used in place of *view
-of an object*. Similarly, the term *type" is used in place of "view of a type".
+of an object*. Similarly, the terms *type* and *subtype* are used in place
+of *view of a type* and *view of a subtype*, respectively.
 
 AARM Note:
 
-  Rules interpreted at compile-time generally refer to views of entities,
+  Rules interpreted at compile time generally refer to views of entities,
   rather than the entities themselves. This is necessary to preserve privacy;
   characteristics that are not visible should not be used in compile-time
   rules. Thus, Static Semantics and Legality Rules generally implicitly have 
-  "view of". Legality Rules that need to ignore the private part (for instance,
-  those involving representation items) are the exception to this interpretation.
+  "view of". Legality Rules that need to look into the private part 
+  are the exception to this interpretation.
 
   On the other hand, run-time rules can work either way, so "view of" should
   not be assumed in Dynamic Semantics rules.
@@ -58,14 +60,37 @@
 as many bugs as it would fix. So we go with a blanket statement.
 
 We have to be careful with the wording, because it is not quite all of the time
-(even at compile-time) that "view of" should be assumed. It is especially hard
+(even at compile time) that "view of" should be assumed. It is especially hard
 to "unassume" it when it is inappropriate. Thus the wording is intentionally vague.
 
-Note that this wording implies that "view of" should not be assumed in dynamic
-rules; any that need "view of" and do not have it are wrong.
-
---!corrigendum 13.9(7)
-
+It should be noted that we were not able to come up with an example of a compile
+time rule that should not assume "view of". In particular, the example of
+representation items for types was suggested, but since those have to be the same
+for all views, there is no difference between using a view of the type and using
+the type itself. In addition, there are a few rules written in terms of the
+full type, which clearly is specifying which view to use. On the other hand,
+given the sheer size of the Ada Standard, it would be foolhardy to assume that
+there is no such case anywhere, and this is a non-critical fix, so we don't want
+it to unintentionally break the standard somewhere else.
+
+Note that the intent (as reflected by the AARM Note) is that "view of" should not
+be assumed in dynamic rules; any that need "view of" and do not have it are wrong.
+
+!corrigendum 3.1(7)
+
+@dinsa
+All declarations contain a @i<definition> for a @i<view> of an entity. A view
+consists of an identification of the entity (the entity @i<of> the view), plus
+view-specific characteristics that affect the use of the entity through that view
+(such as mode of access to an object, formal parameter names and defaults for
+a subprogram, or visibility to components of a type). In most cases, a declaration
+also contains the definition for the entity itself (a renaming_declaration is
+an example of a declaration that does not define a new entity, but instead
+defines a view of an existing entity (see 8.5)).
+@dinst
+When it is clear from context, the term @i<object> is used in place of @i<view
+of an object>. Similarly, the terms @i<type> and @i<subtype> are used in place of
+@i<view of a type> and @i<view of a subtype>, respectively.
 
 !ACATS Test