Re: "out" or "access"

[Matthew Heaney <matthew_heaney@acm.org>]

dewar@gnat.com writes:

> Note that Unchecked_Access still has restrictions which can be annoying, it
> cannot be applied to parameters for example, because it still requires the
> object to be aliased. 

I wish we could liberalize the rules here.  Right now, you can only
apply the Access attribute to an aliased object, which means the object
has to be publically tagged.

I've had to declare types as publically tagged --even though I don't
think the abstraction requires it-- because elsewhere I require an
aliased view.

It would be hipper if you were allowed to use the Access attribute for
objects whose _full_ view is limited or tagged, even if the partial
(public) isn't.

There's a precedent for this: the full view of a type in a generic
package may privately derive from Finalization.Controlled.  This means
instantations can only be done at library level.

This feature of the abstraction isn't stated publically stated -- the
compiler has to tell you at time of instantation.  Why not use a similar
rule for Unchecked_Access: you can only do it if the _full_ view of the
type is limited or tagged, irrespective of what the partial view says.


> In GNAT, the Unrestricted_Access attribute can be used anywhere
> 'Address is usable, and is comparable in effect, except that strong
> typing of the resulting pointer is retained.

This is a very nice attribute, but I've been loathe to use it, because
of potential portability problems.

It would be helpful if all vendors provided at least a weak form of the
Unrestricted_Access attribute.  For example, I don't really care about
downward closures.  But using it to effect type-safe conversion from an
access-to-constant into an access-to-variable seems pretty painless.