References vs access types

References vs access types

[Alejandro R. Mosteo]

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?

Thanks,
Álex.

[1] 
https://www.adacore.com/gems/gem-107-preventing-deallocation-for-reference-counted-types/

Re: References vs access types

[Dmitry A. Kazakov]

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

Re: References vs access types

[Randy Brukardt]

"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.

Re: References vs access types

[AdaMagica]

Am Freitag, 31. Mai 2019 18:55:57 UTC+2 schrieb Dmitry A. Kazakov:
> 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.

I'm quite opposed to Dmitry.

I admit that #1 is clumsy. But see Gem 123 to learn how this syntax may be improved with some aspects.

(Compiler problems are never an argument to avoid some feature forever.)

Re: References vs access types

[AdaMagica]

Am Samstag, 1. Juni 2019 01:55:03 UTC+2 schrieb AdaMagica:
> I'm quite opposed to Dmitry.

Ahem, opposed not to Dmitry as a person. I meant his statement about #1.