CVS difference for ais/ai-00114.txt

Differences between 1.14 and version 1.15
Log of other versions for file ais/ai-00114.txt

--- ais/ai-00114.txt	2005/08/21 06:00:08	1.14
+++ ais/ai-00114.txt	2005/10/31 05:18:06	1.15
@@ -612,6 +612,36 @@
 
 ****************************************************************
 
+From: Jean-Pierre Rosen
+Date: Wednesday, March 2, 2005  2:03 AM
+
+H.3.2(6.a): add "of". Well, native English speakers will tell if the current
+phrasing is correct, but it looks strange to me.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Monday, March 7, 2005  5:10 AM
+
+I find the description in F.3.1(9) a bit puzzling.  It might be good to state
+that it's not possible to create a value of type Picture that corresponds to
+this combination. [Added an AARM note to clarify - ED]
+
+---
+
+In H.4(14.a), "parameter" is not appropriate. It should be "restriction".
+
+---
+
+J.3(6.a): Drop this Bobduffian comment. It doesn't help the reader.
+
+---
+
+J.7.1(23.b): "associate{d}".
+
+
+****************************************************************
+
 From: Randy Brukardt
 Date: Monday, March 21, 2005  10:10 PM
 
@@ -670,7 +700,7 @@
 ****************************************************************
 
 From: Dan Eilers
-Sent: Thursday, April 14, 2004  3:40 AM
+Sent: Thursday, April 14, 2005  3:40 AM
 
 Here are the typos and doubled words: [This list has been edited to
 include only words from existing text - ED]
@@ -730,6 +760,100 @@
 
 ****************************************************************
 
+From: Christoph Grein
+Date: Friday, June 10, 2005  1:03 PM
+
+!topic Inconsistency in AARM explanation for aliased variables
+!reference AARM05-3.10.2(41.b/2 .. d/2)
+!from Grein 05-06-10
+!keywords aliased 'Access
+!discussion
+
+This is a copy of the relevant paragraphs:
+
+{AI95-00363-01} {incompatibilities with Ada 95} Aliased variables are
+not necessarily constrained in Ada 2005 (see 3.6). Therefore, a
+subcomponent of an aliased variable may disappear or change shape, and
+taking 'Access of such a subcomponent thus is illegal, while the same
+operation would have been legal in Ada 95. Note that most allocated
+objects are still constrained by their initial value (see 4.8), and thus
+legality of 'Access didn't change for them. For example:
+
+  type T1 (D1: Boolean := False) is record
+    case D1 is
+      when False => C1: aliased Integer;
+      when True  => null;
+    end case;
+  end record;
+
+  type Acc_Int is access all Integer;
+  A_T: aliased T1;
+  Ptr: Acc_Int := A_T.C1'Access; -- Legal in Ada 2005, illegal in Ada 95
+  A_T:= (D1 => True); -- Raised Constraint_Error in Ada 95, but does not
+                      -- in Ada 2005, so Ptr becomes invalid when this
+                      -- is assigned. 41.c/2 41.d/2
+
+It seems to me that the comment on Ptr contradicts what is said before.
+Also this declaration was legal in Ada 95. (At least Rational Apex let
+this pass and I do not see why this should be illegal.)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, June 10, 2005  1:15 PM
+
+> It seems to me that the comment on Ptr contradicts what is said before.
+> Also this declaration was legal in Ada 95. (At least Rational Apex let
+> this pass and I do not see why this should be illegal.)
+
+Yes, it's backwards. "Illegal in Ada 2006, legal in Ada 95". There were some
+others (on this same topic) with the same problem. They'll all be fixed in
+the next draft.
+
+****************************************************************
+
+From: Dan Eilers
+Date: Friday, June 17, 2005 12:13 AM
+
+ Here are some typos:
+
+
+inferfaces
+   AA-1-2.html
+   RM-1-2.html
+
+namable
+   AA-12-7.html
+   AA-3-2-2.html
+   AA-3-6.html
+   AA-5-4.html
+
+requiremnt
+   AA-13-9-2.html
+
+insure  -> ensure
+   AA-13-13-2.html
+   AA-13-14.html
+   AA-13-3.html
+   AA-13-5-3.html
+   AA-6-5-1.html
+   AA-D-2-6.html
+
+affect of       -> effect of
+   AA-D-2-1.html
+   AA-M-2.html
+   RM-M-2.html
+
+no other effect than  -> no effect other than
+   AA-12-2.html
+   AA-9-4.html
+   AA-B-1.html
+   RM-12-2.html
+   RM-9-4.html
+   RM-B-1.html
+
+****************************************************************
+
 From: Pascal Leroy
 Date: Friday, June 17, 2005  6:35 AM
 
@@ -844,8 +968,110 @@
 
 ****************************************************************
 
+From: Christoph Grein
+Date: Friday, September 16, 2005  10:28 AM
+
+13.11.2(17.a)
+This is not a testable property, since we do not {know} how much
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, September 29, 2005  11:58 PM
+
+> B.1(41.c)
+> This paragraph is no longer correct since C++ has been an ISO
+> standard for some time now.
+
+I'm not sure what to do with this one. We didn't move the preceding
+paragraph to real Implementation Advice, and it seems too late to do so now.
+Moreover, such advice would seem to conflict with the normative wording
+suggesting to use C for this purpose (that is, AI-376). So it's not clear to
+me that that would be a good idea.
+
+OTOH, I can't think of any justication for keeping 41.b as it is. So a
+rewrite of 41.c doesn't make much sense.
+
+This leads into the more general question of time-dependent notes in the
+AARM. Do we try to update them all, or do we just leave old text alone with
+the understanding that what was true in 1995 might not be true now? (I'm
+pretty sure there are other cases like this in the AARM, but I can't point
+to any offhand.)
+
+Anyway, it seems to me that we have the following options:
+
+1) Do nothing. (My preference).
+2) Change just "(as of this writing)" to "(as of the writing of RM95)". But
+then the note is still bogus, we're just more clearly blaming that on Bob
+and Tuck.
+3) Delete both 41.b and 41.c (41.b as being inconsistent with AI-376, and
+41.c as it explains 41.b).
+4) Hold up finishing the Amendment until we can discuss whether this should
+be first-class Advice in B.3 (after 71.1, I suppose). Yuck.
+
+Comments?
+
+****************************************************************
+
+From: Bob Duff
+Date: Friday, September 30, 2005  11:07 AM
+
+> 1) Do nothing. (My preference).
+> 2) Change just "(as of this writing)" to "(as of the writing of RM95)". But
+> then the note is still bogus, we're just more clearly blaming that on Bob
+> and Tuck.
+> 3) Delete both 41.b and 41.c (41.b as being inconsistent with AI-376, and
+> 41.c as it explains 41.b).
+> 4) Hold up finishing the Amendment until we can discuss whether this should
+> be first-class Advice in B.3 (after 71.1, I suppose). Yuck.
+
+I prefer 1, because it's easiest.  Second choice -- 2.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Monday, October 3, 2005  1:55 AM
+
+I think 41.b is still valuable.  An implementation might want to support
+interfacing with C++ (beyond the subset that corresponds to C) and if it
+does 41.b provides a modicum of uniformity.
+
+I don't think we want to draw attention to the fact that we don't address
+full-fledged interfacing with C++ in the Amendment, so making this a
+first-class issue would be a bad idea.
+
+I would suggest to merely drop the second sentence of 41.c and be done
+with it: we recommend the identifier C_Plus_Plus, and we do so for
+uniformity.
+
+In addition we could change 41.b to read:
+
+"If an implementation supports interfacing to the C++ entities not covered
+by B.3, it should do so via the convention identifier C_Plus_Plus (in
+additional to any C++-implementation-specific ones)."
+
+That would have the advantage of being more consistent with the changes
+that were made to B.3.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Monday, October 3, 2005  4:24 AM
+
+I would suggest:
+5) Delete both 41.b and 41.c, and add the following to AI376:
+
+Implementation advice:
+If an implementation supports interfacing to C++ beyond the facilities
+that are common with C, it should do so via the convention identifier
+C_Plus_Plus (in additional to any C++-implementation-specific ones).
+
+And have an E-mail ballot on this.
+
+****************************************************************
+
 From: Randy Brukardt (Editor)
-Date: August 16, 2005
+Date: October 16, 2005
 
 I've made the corrections needed to implement the presentation issues
 above in the updated AARM (Amendment 1 version), or explained why the suggested

Questions? Ask the ACAA Technical Agent