Re: How can one record component be local and another not?

[Jere <jhb.chat@gmail.com>]

On Tuesday, May 5, 2020 at 8:59:21 AM UTC-4, hreba wrote:
> On 5/5/20 1:33 PM, AdaMagica wrote:
> > Am Dienstag, 5. Mai 2020 13:04:56 UTC+2 schrieb hreba:
> >> I have reduced my problem to the following example:
> >>
> >> package Aux is
> >>      type Integer_P is access all Integer;
> >>      type Rec is record
> >>         a: aliased Integer;
> >>         p: Integer_P;
> >>      end record;
> >>
> >>      procedure Init (r: in out Rec);
> >> end Aux;
> >>
> >> package body Aux is
> >>      procedure Init (r: in out Rec) is
> >>      begin
> >>         r.p:= r.a'Access;  -- <-- error!
> >>      end Init;
> >> end Aux;
> > 
> > Imagine you define a local Rec:
> > 
> > with Aux;
> > procedure Proc is
> >    R: Aux.Rec;
> > begin
> >    Aux.Init (R);
> > end Proc;
> > 
> > Now R has shorter lifetime than the access type Integer_P. Thus you might have somewhere an access object AO with longer lifetime than R and try to assign
> > AO := R.P;
> > 
> > Try Unrestricted_Access.
> > 
> 
> Don't understand that. R.a and R.p have exactly the same lifetime, which 
> is the lifetime of R, haven't they?
> 

You are thinking about it in a way that looks at object lifetimes
only.  Ada often compares the lifetime of the access "type" to the lifetime
of the object (called accessibility levels in the RM).  I'm not 
sure why the decision to do it that way was made (I assume easier
implementation at the time).  I do know that some younger languages
have worked out some pretty useful schemes for tracking object lifetimes
along with the access variables.  Rust comes to mind and SPARK is also
coming along in that area as well.  Additionally there are some rules
concerning anonymous access types that allow a runtime checking of object
lifetimes (as opposed to static checking of Rust and soon SPARK), but
anonymous access types have a host of issues all their own and I don't
know them well enough to comment on how to do that reliably.