[The attribute Unchecked_Access is used to create
access values in an unsafe manner — the programmer is responsible
for preventing “dangling references.”]
All rules and semantics that
apply to X'Access (see
3.10.2) apply also
to X'Unchecked_Access, except that, for the purposes of accessibility
rules and checks, it is as if X were declared immediately within a library
package.
{Access attribute: See also
Unchecked_Access attribute}
Reason: {
AI95-00254-01}
Such an attribute would allow
unsafe “downward
closures”, where an access value designating a more nested subprogram
is passed to a less nested subprogram.
(Anonymous
access-to-subprogram parameters provide safe “downward closures”.)
This requires some means of reconstructing the global environment for
the more nested subprogram, so that it can do up-level references to
objects. The two methods of implementing up-level references are displays
and static links. If
unsafe downward closures
were supported, each access-to-subprogram value would have to carry the
static link or display with it.
We don't want to
require the space and time overhead of requiring the extra information
for all access-to-subprogram types, especially as including it would
make interfacing to other languages (like C) harder In
the case of displays, this was judged to be infeasible, and we don't
want to disrupt implementations by forcing them to use static links if
they already use displays.
If desired, an instance of Unchecked_Conversion
can be used to create an access value of a global access-to-subprogram
type that designates a local subprogram. The semantics of using such
a value are not specified by the language. In particular, it is not specified
what happens if such subprograms make up-level references; even if the
frame being referenced still exists, the up-level reference might go
awry if the representation of a value of a global access-to-subprogram
type doesn't include a static link.