Version 1.2 of ai05s/ai05-0054-4.txt

Unformatted version of ai05s/ai05-0054-4.txt version 1.2
Other versions for file ai05s/ai05-0054-4.txt

!standard 3.3(13)          08-11-01 AI05-0054-4/01
!standard 13.9.1(13)
!class binding interpretation 08-11-01
!status No Action (7-0-1) 08-11-02
!status work item 08-10-01
!status received 08-11-01
!priority Low
!difficulty Hard
!qualifier Omission
!subject Variable views of constant objects
Remove erroneousness associated with using access-to-variable values designating constants of controlled and immutably limited private types, so long as they originate at a point where the language provides an aliased variable view of the constant.
Revise the definition of constant objects and views for the above without contradictions.
The current instance of a limited type can be used to obtain a variable aliased view of a (limited) constant object.
Are runtime checks needed in order to prevent the modification of a constant?
No, 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 instance (See the discussion section for more rationale.)
As the present concept of constant objects needs to be broken, it should only be broken for private types, where the need for internal state changes is not visible to the user of the type.
Modify 3.3.1(6) as follows:
An object_declaration with the reserved word constant declares a constant object{, unless the subtype_indication denotes a private type. In the latter case, the object_declaration declares a constant view of a variable object.} If {an object_declaration} [it] has an initialization expression, then it is called a full constant declaration. Otherwise it is called a deferred constant declaration. The rules for deferred constant declarations are given in clause 7.4. The rules for full constant declarations are given in this subclause.
Modify 13.9.1(13) as follows:
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 an object of a controlled private or immutably limited private type}. [Redundant: [Such an]{An} access value {whose dereference is 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 from an aliased variable view of a controlled or immutably limited constant of a private type, 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").
The notion of specified constantness of objects should be preserved as much as possible. In particular, the visible components of an object declared to be "constant" should indeed be immutable.
The argument becomes somewhat weaker, when privateness is involved, on the grounds that implementation semantics might go on that require changes to internal state stored in the object but are not to be visible to the user of the private type. This is particularly true for limited private types, where the state change can only be discovered by operations provided with the type. Many predefined packages in Ada have taken this attitude, as expressed by "in" parameters for actuals, whose internals need to be changed by the subprogram. The Rosen-Trick was invented to get around this particular problem of modifying "in" parameters. The Rosen-Trick ist fully supported by the language today, except if the actual is a declared constant. As the writer of a subprogram, it is unsatisfactory, however, that a call with a constant object as actual is deemed erroneous, since it changes the value of the constant. His only choices to stay on the safe side is to either use the heap or admit to the change of internal state by making the parameter "in out".
A compromise is needed between a general concept of constant objects and the desire for the abstraction of hiding internal state changes. Therefore the proposal separates the constantness concept of private and non-private types. For private types, an object_declaration creates only a constant view of the object, thus allowing for internal state changes via variable views, while, for non-private types, the constantness of the object itself remains guaranteed.
We use the phrase "originate from an attribute_reference applied to a variable view" to allow for possible type conversions after the initial '[Unchecked_]Access that created the access-to-variable value. Hopefully that is clear enough. The key thing is that you have to have a variable view at some point, or else somebody cheated. Moreover, we require that variable view to be aliased and originate from a controlled private or immutably limited private type, so that uses of 'Address and uses of Address_to_Access_Conversions are excluded from the exception (thus modifying a non-limited untagged type this way is still erroneous).
!ACATS test
There should be C-Tests that an access-to-variable view of a constant object works properly.

Questions? Ask the ACAA Technical Agent