From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: References vs access types
Date: Fri, 31 May 2019 16:33:18 -0500
Organization: JSA Research & Innovation
Message-ID: <qcs6iv$29u$1@franka.jacob-sparre.dk>
References: <qcri52$1tn$1@dont-email.me>
Injection-Date: Fri, 31 May 2019 21:33:19 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="2366"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader01.eternal-september.org comp.lang.ada:56426
Date: 2019-05-31T16:33:18-05:00
List-Id: <comp.lang.ada>


"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:qcri52$1tn$1@dont-email.me...
> Sorry if I asked something similar in the past. I have a foggy memory of 
> having wanted to do so. I have also checked some old threads that 
> tangentially touch my question but without direct explanation.
>
> So, part of the point of reference types is to be able to return an item 
> "by reference" without being able to store the pointer:
>
>    type Item;
>    type Item_Access is access Item;
>
>    type Reference (Ptr : access Item) is limited null record;
>
>    function Get (...) return Reference; -- (1)
>
> In Gem #107 this is said as advantageous against, for example,
>
>    function Get (...) return Item_Access; -- (2)
>
> because "access discriminants are unchangeable. The discriminant also 
> cannot be copied to a variable [like Item_Access]" [1].
>
> Now, without thinking much about it, while fighting old bugs, I have 
> sometimes replaced a problematic Reference with
>
>    function Get (...) return access Item; -- (3)
>
> And here comes the question: besides losing the ability to use aspects on 
> the Reference type, or using it for some fancy refcounting, does (3) give 
> the same safeties wrt to copying as (1)? Are there any other hidden traps 
> in (3) (assuming the pointee thread-safety/lifetime is properly managed)?
>
> Or, put it another way, is (1) always preferable? Or may (3) suffice for 
> simple uses?

(1) and (3) have the same accessibility rules, so they have the same safety 
from copying (no more and no less). However, since (3) is returning an 
access type, one can directly assign the function result into an access 
type, and that will work as the function will then have the accessibility of 
the access value. (But of course, you might get an accessibility failure 
inside the function in that case.)

An important part of the reference mechanism is the use of aliased 
parameters. For a function, those are required to have the same 
accessibility as the function result. This makes most problematic calls 
illegal. For instance, in:

    function Get (Obj : aliased in out Some_Type) return access 
Some_Other_Type;

   Ptr : Some_Access_Type;

   procedure Whatever is
      Local: Some_Type;
   begin
      Ptr := Get (Local); -- Illegal.
      Get (Local).all := ...;
   end Whatever;

The first call to Get here is illegal as the actual parameter is more nested 
than the level of the function call (which is that of Ptr). This prevents 
Get from keeping a pointer longer than the object exists. The second call to 
Get is legal because the level of that call is local, and therefore the 
object lives long enough.

                                     Randy.