CVS difference for ais/ai-00373.txt
--- ais/ai-00373.txt 2005/08/05 04:36:42 1.9
+++ ais/ai-00373.txt 2005/10/31 05:18:38 1.10
@@ -1,4 +1,4 @@
-!standard 03.03.01(08) 05-07-20 AI95-00373/07
+!standard 03.03.01(08) 05-10-12 AI95-00373/08
!standard 03.03.01(18/1)
!standard 03.03.01(19)
!standard 03.03.01(20)
@@ -49,7 +49,7 @@
A component of an object is said to *require late initialization*
if it has an access discriminant value constrained by a per-object
- expression, or if it has an initialization expression which includes a name
+ expression, or if it has an initialization expression that includes a name
denoting the current instance of the type or denoting an access discriminant.
Replace 3.3.1(18/1 - 20) with
@@ -239,7 +239,7 @@
@dinst
A component of an object is said to @i<require late initialization>
if it has an access discriminant value constrained by a per-object
-expression, or if it has an initialization expression which includes a name
+expression, or if it has an initialization expression that includes a name
denoting the current instance of the type or denoting an access discriminant.
!corrigendum 3.3.1(18/1)
@@ -580,5 +580,88 @@
I'm not sure it belongs in the standard because it seems that 13.9.1 already
covers this. Note the words "and any explicit or default initializations have
been performed" in 13.9.1(4).
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 6, 2005 12:33 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+3.3.1(18.a) says:
+
+ 18.a Discussion: For a per-object constraint that contains some
+ per-object expressions and some non-per-object expressions, the
+ values used for the constraint consist of the values of the
+ non-per-object expressions evaluated at the point of the
+ type_declaration, and the values of the per-object expressions
+ evaluated at the point of the creation of the object.
+
+Is this still correct, given new rules about per-object constraints?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 6, 2005 4:33 PM
+
+I would say it is still true. We might have changed the
+order in which things are done, but the notion of what
+is a "per-object constraint" hasn't changed.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005 3:41 AM
+
+I agree.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 6, 2005 12:34 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+3.3.1(20.h/2):
+
+ 20.h/2 It is possible for there to be more than one component that
+ requires late initialization. In this case, the language can't
+ prevent problems, because all of the components can't be the last
+ one initialized. In this case, we specify the order of
+ initialization for components requiring late initialization; by
+ doing so, programmers can arrange their code to avoid accessing
+ uninitialized components, and such arrangements are portable. Note
+ that if the program accesses an uninitialized component, 13.9.1
+ defines the execution to be erroneous.
+ ^^^^^^^^^
+Shouldn't that be "bounded error"?
+
+****************************************************************
+
+From: Stephen W Baird
+Sent: Monday, June 6, 2005 2:54 PM
+
+> Shouldn't that be "bounded error"?
+
+No; I think that "erroneous" is correct here.
+
+13.9.1(4) states that an object is not guaranteed to be normal until "any
+explicit or default initializations have been performed".
+13.9.1(8) states that "it is erroneous to evaluate ... an abnormal
+object".
+
+Note that we're not just talking about invalid scalars here - we're
+talking about uninitialized access values, tasks, discriminants, etc.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005 3:25 AM
+
+> Shouldn't that be "bounded error"?
+
+I believe it is definitely "erroneous", since we are talking accessing
+discriminants before they have been initialized and other very nasty
+things here.
****************************************************************
Questions? Ask the ACAA Technical Agent