CVS difference for ai05s/ai05-0054-2.txt
--- ai05s/ai05-0054-2.txt 2008/02/28 07:45:51 1.5
+++ ai05s/ai05-0054-2.txt 2008/12/02 06:01:19 1.6
@@ -1,6 +1,9 @@
-!standard 3.3(13) 08-02-27 AI05-0054-2/04
+!standard 3.3(13) 08-11-26 AI05-0054-2/05
+!standard 3.3(25)
!standard 13.9.1(13)
!class binding interpretation 07-10-24
+!status Amendment 201Z 08-11-26
+!status ARG Approved 7-0-1 08-11-02
!status work item 07-10-24
!status received 07-10-24
!priority Low
@@ -24,11 +27,11 @@
a variable aliased view of a (limited) constant object.
Are runtime checks needed in order to prevent the
-modification of a constant?
+modification of a constant? (No.)
!recommendation
-No, the practice of obtaining such a variable aliased view during
+The practice of obtaining such a variable aliased view during
initialization is an existing idiom, and should be allowed to continue
even if the object is declared constant. A similar idiom exists for
controlled types using Initialize and Adjust rather than the current
@@ -43,14 +46,22 @@
between its initialization and its finalization, whereas
the value of a variable object can be changed.] Similarly,
a view of an object is either a constant or a variable.
- [All views of a constant object are constant.] {A name
- that statically denotes a constant object denotes a constant
- view. A name that statically denotes a variable object
- denotes a variable view.} A constant view of [a variable]
- {an} object cannot be used to modify [the value of the
- variable] {its value}. The terms constant and variable
+ All views of a constant {elementary }object are constant.
+ {All views of a constant composite object are constant,
+ except for parts that are of controlled or immutably limited
+ types; variable views of those parts and their subcomponents
+ may exist. In this sense, objects of controlled and immutably
+ limited types are inherently mutable.} A constant view of
+ [a variable] {an} object cannot be used to modify [the value of
+ the variable] {its value}. The terms constant and variable
by themselves refer to constant and variable views of objects.
+Add a new NOTE after 3.3(25):
+
+ The value of a constant object cannot be changed after its initialization,
+ except in some cases where the object has a controlled or immutably limited part
+ (see 7.5, 7.6, and 13.9.1).
+
Modify 13.9.1(13) as follows:
The dereference of an access value is erroneous if it does not
@@ -64,12 +75,15 @@
erroneous} can exist, for example, because of Unchecked_Deallocation,
Unchecked_Access, or Unchecked_Conversion.]
- AARM NOTE: We permit the use of access-to-variable values
- that designate constant objects so long as they originate
+ AARM NOTE (replacing 13.9.1(13.b)): We permit the use of access-to-variable
+ values that designate constant objects so long as they originate
from an aliased variable view of a controlled or immutably limited
constant, such as during the initialization of a constant (both via
the "current instance" and during a call to Initialize) or during an
- assignment (during a call to "Adjust").
+ assignment (during a call to Adjust).
+
+[Note: This wording depends on the definition of "immutably limited" from
+AI05-0052-1.]
!discussion
@@ -105,6 +119,67 @@
excluded from the exception (thus modifying a non-limited untagged
type this way is still erroneous).
+!corrigendum 3.3(13)
+
+@drepl
+An object is either a @i<constant> object or a @i<variable>
+object. The value of a constant object cannot be changed
+between its initialization and its finalization, whereas
+the value of a variable object can be changed. Similarly,
+a view of an object is either a @i<constant> or a @i<variable>.
+All views of a constant object are constant. A constant
+view of a variable object cannot be used to modify the value
+of the variable. The terms constant and variable by themselves
+refer to constant and variable views of objects.
+@dby
+An object is either a @i<constant> object or a @i<variable>
+object. Similarly, a view of an object is either a @i<constant>
+or a @i<variable>. All views of a constant elementary object
+are constant.
+All views of a constant composite object are constant,
+except for parts that are of controlled or immutably limited
+types; variable views of those parts and their subcomponents
+may exist. In this sense, objects of controlled and immutably
+limited types are @i<inherently mutable>. A constant view of
+an object cannot be used to modify its value. The terms constant
+and variable by themselves refer to constant and variable views
+of objects.
+
+!corrigendum 3.3(25)
+
+@dinsa
+@xindent<@s9<NOTES@hr
+5 A constant cannot be the target of an assignment operation, nor be
+passed as an @b<in out> or @b<out> parameter, between its initialization
+and finalization, if any.>>
+@dinst
+@xindent<@s9<6 The value of a constant object cannot be changed after its
+initialization, except in some cases where the object has a controlled or
+immutably limited part (see 7.5, 7.6, and 13.9.1).>>
+
+
+!corrigendum 13.9.1(13)
+
+@drepl
+The dereference of an access value is erroneous if it does not
+designate an object of an appropriate type or a subprogram with
+an appropriate profile, if it designates a nonexistent object,
+or if it is an access-to-variable value that designates a
+constant object. Such an access value can exist, for example,
+because of Unchecked_Deallocation, Unchecked_Access, or
+Unchecked_Conversion.
+@dby
+The dereference of an access value is erroneous if it does not
+designate an object of an appropriate type or a subprogram with
+an appropriate profile, if it designates a nonexistent object,
+or if it is an access-to-variable value that designates a
+constant object and it did not originate from an
+attribute_reference applied to an aliased variable view
+of a controlled or immutably limited object.
+An access value whose dereference is erroneous can exist,
+for example, because of Unchecked_Deallocation,
+Unchecked_Access, or Unchecked_Conversion.
+
!ACATS test
There should be C-Tests that an access-to-variable view of a constant object
@@ -1907,6 +1982,143 @@
But as I point out, in your conceptual sense, it could NEVER be true,
so it is a bit meaningless to adopt this conceptual sense.
+
+****************************************************************
+
+From: Erhard Ploederder
+Sent: Monday, November 24, 2008 3:54 PM
+
+I had the homework to create a NOTE about immutable constants.
+
+Here goes:
+-----------------------------
+
+Add after 3.3(25):
+
+The value of a constant object cannot be changed after its initialization, unless
+the object has a controlled part or a part that is limited at the point of its
+declaration (see 7.5 and 7.6).
+
+-----
+A bit of rationale:
+
+I left out the finalization bit, since for the types in question, finalization
+can only be trivial.
+
+The terminology on "controlled" parallels the verbage of 7.6 (10/2). If it is
+wrong here, it is likely to be wrong there, too. For limited, I needed to
+account for constant objects whose limited part became non-limited for
+crucial moments.
+
+My first version read:
+The value of a constant object cannot be changed after its initialization,
+unless the object has a controlled part or limited part (see 7.5 and 7.6).
+
+This looked nice and simple, except for a "becomes unlimited"-situation.
+Maybe, as a user note, it would suffice regardless.
+
+My second version was:
+The value of a constant object cannot be changed after its initialization, unless
+the object has a controlled part or limited part at the point of its declaration
+(see 7.5 and 7.6).
+
+This causes a contract question on "controlled", which could hide behind "private".
+
+So, I ended up with the above, which is as good or bad as 7.6 (10/2) wrt the
+"controlled behind private" argument.
+
+The text of this Note could also be used in lieu of the deleted
+ [The value of a constant object cannot be changed
+ between its initialization and its finalization, whereas
+ the value of a variable object can be changed.] if one wanted to. In that case,
+it should continue:
+In all other cases, the value of an object can be changed.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 24, 2008 4:17 PM
+
+> The terminology on "controlled" parallels the verbage of 7.6 (10/2).
+> If it is wrong here, it is likely to be wrong there, too. For limited,
+> I needed to account for constant objects whose limited part became
+> non-limited for crucial moments.
+
+Any particular reason that you did not use "immutably limited" in this wording,
+as is done in both parts of the new normative wording? This wording is actually
+slightly broader than needed, since it seems to include a type which is limited
+by having a limited component (not necessarily immutably limited).
+
+We used to have a whole bunch of different ways of saying "immutably limited",
+but supposedly we've changed them all to use the new term. "Immutably limited"
+is (already) used in 7 subclauses (and the index) and roughly 15 occurrences
+in the revised AARM. It's a term that should quickly become familiar -- so I
+don't think there is any good reason to avoid it.
+
+I suppose that there is some value to explaining the rules in different terms,
+but then it is odd that you're leaning on the defined term for "controlled" and
+not for "immutably limited".
+
+If you're not going to worry about whether you include too much in the note, then
+I think I actually prefer your first wording:
+
+"The value of a constant object cannot be changed after its initialization, unless
+the object has a controlled part or limited part (see 7.5 and 7.6)."
+
+because this is still a true statement (there are some objects with limited parts
+that cannot be changed after initialization, but there aren't any objects that can
+be changed that are not covered by the "unless"). The only extra cases covered by
+the "unless" that don't have to be covered involve using limited private types that
+have full types that aren't limited. And writing code that assumes that a limited
+private type is implemented by something non-limited (and thus gets covered by
+this note) sounds pretty dubious to me -- it makes the usage depend on the actual
+implementation of the private type.
+
+So for actual use, the simpler version probably is a good enough rule of thumb to
+remember.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 24, 2008 4:33 PM
+
+> "The value of a constant object cannot be changed after its
+> initialization, unless the object has a controlled part or limited part (see 7.5
+> and 7.6)."
+
+Seems to imply that if it has a "controlled part or limited part", it can be
+changed willy-nilly. And "controlled part or limited part" = "controlled or
+limited part".
+
+So how about:
+
+"The value of a constant object cannot be changed after its initialization, except
+in some cases where the object has a controlled or limited part (see 7.5 and 7.6)."
+
+****************************************************************
+
+From: Erhard Ploederder
+Sent: Tuesday, November 25, 2008 8:25 PM
+
+Randy asked, why I didn't use "immutably limited".
+
+Mainly, because I used the Springer book rather than the AARM to leaf through
+definitions. So, no technical reason. It merely hasn't sunk in as new terminology
+with me and so I would not have felt comfortable. Reading the modified 13.9.1(13)
+in the AI, I guess it would be ok to add the "immutably" to the text.
+
+The "part"-part came from someone's observation at the meeting that it sufficed
+to have a subcomponent of the ilk to make the enclosing constant object mutable
+(merely by the fact that the subcomponent could be altered).
+That made sense to me.
+
+Bob's observations were good ones, too.
+
+How about:
+
+The value of a constant object cannot be changed after its initialization, except
+in some cases where the object has a controlled or immutably limited part (see 7.5,
+7.6 and 13.9.1).
****************************************************************
Questions? Ask the ACAA Technical Agent