CVS difference for 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(19.bb/2), 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