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!aioe.org!.POSTED.3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: References vs access types
Date: Fri, 31 May 2019 18:55:53 +0200
Organization: Aioe.org NNTP Server
Message-ID: <qcrmap$j58$1@gioia.aioe.org>
References: <qcri52$1tn$1@dont-email.me>
NNTP-Posting-Host: 3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
Xref: reader01.eternal-september.org comp.lang.ada:56424
Date: 2019-05-31T18:55:53+02:00
List-Id: <comp.lang.ada>

On 2019-05-31 17:44, Alejandro R. Mosteo wrote:
> 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?

My preferences list would be:

#1 - Never, visually ugly, semantically questionable, lacking 
transparent access to the target object and technically not a reference 
at all, plus unstable with GNAT compilers

#2 - Construction of new stand-alone objects (frequently class-wide), 
implementation-dependent stuff

#3 - Access to a component of an existing object

As for hidden traps, only #3 is safe upon inheritance, if primitive 
operation and thus covariant.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de