* References vs access types
@ 2019-05-31 15:44 Alejandro R. Mosteo
2019-05-31 16:55 ` Dmitry A. Kazakov
2019-05-31 21:33 ` Randy Brukardt
0 siblings, 2 replies; 5+ messages in thread
From: Alejandro R. Mosteo @ 2019-05-31 15:44 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: References vs access types
2019-05-31 15:44 References vs access types Alejandro R. Mosteo
@ 2019-05-31 16:55 ` Dmitry A. Kazakov
2019-05-31 23:55 ` AdaMagica
2019-05-31 21:33 ` Randy Brukardt
1 sibling, 1 reply; 5+ messages in thread
From: Dmitry A. Kazakov @ 2019-05-31 16:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: References vs access types
2019-05-31 16:55 ` Dmitry A. Kazakov
@ 2019-05-31 23:55 ` AdaMagica
2019-05-31 23:56 ` AdaMagica
0 siblings, 1 reply; 5+ messages in thread
From: AdaMagica @ 2019-05-31 23:55 UTC (permalink / raw)
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.)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: References vs access types
2019-05-31 15:44 References vs access types Alejandro R. Mosteo
2019-05-31 16:55 ` Dmitry A. Kazakov
@ 2019-05-31 21:33 ` Randy Brukardt
1 sibling, 0 replies; 5+ messages in thread
From: Randy Brukardt @ 2019-05-31 21:33 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-05-31 23:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-31 15:44 References vs access types Alejandro R. Mosteo
2019-05-31 16:55 ` Dmitry A. Kazakov
2019-05-31 23:55 ` AdaMagica
2019-05-31 23:56 ` AdaMagica
2019-05-31 21:33 ` Randy Brukardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox