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

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

--- ai05s/ai05-0005-1.txt	2012/01/05 06:19:31	1.42
+++ ai05s/ai05-0005-1.txt	2012/01/27 23:23:09	1.43
@@ -2674,6 +2674,22 @@
+From: John Barnes
+Sent: Thursday, December 22, 2011  8:47 AM
+[A small part of a larger review.]
+> A.4.3(109.d/3)   It says "newly added"  I would delete 
+> "newly".  It might seem odd in a couple of years time.
+[Editor's note: There are quite a few of these, and several in
+Ada 2005 text as well: 3.9(33.d/2), 11.4.1(, A.4.1(6.a/2),
+A.4.3(109.a/2), A.4.4(106.f/2), A.4.5(88.c/2), A.10.7(26.a/2), B.3(84.a/2),
+D.8(51.a/2). Ada 2012 occurrrences are just changed, Ada 2005 notes are marked
+and listed here.]
 From: Brad Moore
 Sent: Wednesday, December 28, 2011  10:46 AM
@@ -2688,8 +2704,76 @@
 [Editor's note: There is a similar problem in A.18.2(137.a/2).]
+From: Bob Duff
+Sent: Friday, January 13, 2012  7:55 PM
+[Just the relevant parts of a larger review. - Editor]
+> 3.3 Objects and Named Numbers
+> 23.b/3      There are other cases that could have been included in this
+>             definition (view conversions, the current instance of a type,
+>             implementation-defined attributes, objects of a formal
+>             discriminated private type), but these are not relevant to the
+>             places this term is used, so they were not included. If this term
+>             is used in additional places, the definition should be checked to
+>             see if any of these additional cases are relevant and appropriate
+>             wording added if necessary.
+I suggest you remove "implementation-defined attributes".
+If it's impl-def, then the implementation gets to decide whether it is
+"known to be constrained", or any other property.
+> 3.7.2 Operations of Discriminated Types
+> 3.c/3       Discussion: {AI05-0214-1} If the type of A is a type derived from
+>             an untagged partial view of a tagged type such that it is not a
+>             tagged type, then A is not considered a tagged object, and
+>             A'Constrained can return either True or False.
+I find that confusing -- it sounds like the implementation is 
+allowed to roll dice, and return whatever it likes.  I think 
+adding, ", depending on the nature of the type", or ", 
+depending on whether defaults exist"
+at the end would help.
+[Editor's note: "depending on the nature of the object" was used, because the
+object determines the value; the type only does if it is tagged.]
+> 3.9.2 Dispatching Operations of Tagged Types
+> 20.a.1/3    Ramification: {AI05-0126-1} "Corresponding dispatching
+>             operation" refers to the inheritance relationship between subprograms.
+>             Primitive operations are always inherited for a type T, but they
+>             may not be declared if the primitive operation is never visible
+"may not" --> "might not"
+>             within the immediate scope of the type T. If no corresponding
+>             operation is declared, the last bullet is used and the
+>             corresponding operation of the parent type is executed (an
+>             explicit body that happens to have the same name and profile is
+>             not called in that case).
+[Editor's note: this also occurs in 3.9(12.a/2) and 3.9.2(20.a.2/3).]
+> 3.10.2 Operations of Access Types
+> 15.a/3      Discussion: {AI05-0014-1} This rule applies even when no
+>             dereference exists, for example when an access value is passed as
+>             an access parameter. This rule ensures that implementations are
+>             not required to include dynamic accessibility values with access
+>             values.
+That seems wrong.  Dynamic accessibility values are needed 
+for access parameters and standalone variables, I think.
+["all" is missing before "access values" - Editor.]
-Editor's note (December 30, 2011): All of the items above this
+Editor's note (January 21, 2012): All of the items above this
 marker have been included in the working version of the AARM.

Questions? Ask the ACAA Technical Agent