Version 1.2 of ai05s/ai05-0054-3.txt
!standard 3.3(13) 08-11-01 AI05-0054-3/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-11-01
!status received 08-11-01
!priority Low
!difficulty Hard
!qualifier Omission
!subject Variable views of constant objects
!summary
Modifying a constant by means of an access-to-variable value remains erroneous.
!question
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.]
!recommendation
No change should be made to the language to solve this issue. See the
discussion.
!wording
None needed.
!discussion
The present state of the language ensures that an entity declared with
the keyword "constant" is indeed constant in the usual sense of the
word, i.e., cannot have its value after it has been initialized (and
is not yet being finalized), short of applying unsafe or erroneous
programming idioms. Thus the specification implied by the keyword
"constant" both by present language rules and by common-sense is
preserved by language guarantees. This is of considerable value to the
users interested in reliability, safety and security. Of course, a
language should preserve a specified object property and Ada05
presently does so.
On the other hand, the practice of obtaining a variable aliased view
of objects of limited or controlled type during initialization is an
existing idiom that should have a well-defined meaning. This practice
is important to provide a practical way of changing the value of "in"
parameters, when internal state of the object needs to be changed, but
the designer of the interface decided that this "was not the user's
business to know". This idiom is generally known as the
Rosen-Trick. At present, the semantics of the idiom are well-defined
for variable objects as actual parameters of such "in" parameters.
However, they are erroneous for constant objects, since the
Rosen-Trick then breaks the specification "constant" of the actual.
It follows that, for users of limited (and controlled) types, there is
a simple write-around to stay out of erroneousness: Do not declare
objects of limited (and controlled) types to be "constant". Given that
a limited type lacks assignment anyhow, the semantic difference is
marginal: As "constant", the object cannot be passed to "in out"
parameters to be changed legally; it can only be passed to "in"
parameters where it might be changed (erroneously) by the Rosen-Trick.
For writers of libraries, there is an equally simple write-around: do
not use an "in" parameter, where the value of the parameter will be
changed by the implementation, and thus the Rosen-Trick is not needed.
On balance, trading the well understood principle of constantness of
objects against a weaker notion that negates the existence of constant
objects alltogether and ties constantness to each separate view of a
variable, merely to render the Rosen-Trick well-defined for constants
as well, is not warranted.
Other alternatives that were considered:
a) raise a run-time exception (AI05-0054-1): apart from implementation
overhead, merely eliminates erroneousness, but does not solve the
Rosen-Trick issues.
b) restrict the damage to the constantness concept to constants of
limited and controlled types, which become constant views only
(AI05-0054-4)
c) restricting it further to private types (could easily be added to
the semantics of 13.9.1(13) in AI05-0054-4 by mandating that
the the access-to-variable value originate from an
attribute_reference applied to an aliased variable view
of a controlled or immutably limited object of a private type )
d) obsolesce the notion of constants of limited and controlled types
altogether on the grounds that the definer cannot know (not written up).
!ACATS test
Testing erroneousness is not possible.
!appendix
Questions? Ask the ACAA Technical Agent