Re: References vs access types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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