Re: Overloading operator "=" for anonymous access types?

[Jere <jhb.chat@gmail.com>]

On Thursday, January 17, 2019 at 5:22:49 PM UTC-5, Randy Brukardt wrote:
> "Jere" wrote in message 
> ...
> > I mostly find myself using them in situations where I need to save an
> > access variable of an object that doesn't live as long as the access
> > type involved.  I can't do that safely with named access types.
> 
> You should have just stopped at "safely": "I can't do that safely." So far 
> as I know, the only way to do that with anonymous access (other than 
> parameters) is to used Unchecked_Access. And in the case of the parameters, 
> you should just have passed the designated object.

It can be done safely, but just not using Ada's current paradigm. There
are other safety minded languages that have figured out how to do it
without needing to check against their equivalent of an access type's
lifetime.  They can do it based on the lifetime of the actual
[their equivalent to] access object vs the lifetime of the object it 
points to (at compile time).

> 
> > For
> > example, using them in containers (need the access type for iterators,
> > cursors, etc.) but creating those container objects inside an operation
> > of some form.  I feel like having to use Unchecked_Access somewhat
> > defeats the purpose of using Ada (not all of it, just some).
> 
> Ada accessibility checks are designed for a particular use case: that of 
> programs that cannot allow dynamically allocated objects but still need 
> accesses. In such a case, all of the objects are typically globally 
> allocated and managed in some way.
Which is particularly important in bare metal environments and smaller
embedded environments as well.  Even just messing around with some custom
bounded containers leads me down this rabbit hole.

> 
> <SNIPPED>
> 
> > Are there any plans to add smarter and more relaxed named access types
> > in the future?  Something akin to rust references (especially with
> > the recently released non lexical lifetimes update)?  It's definitely
> > possible to track references in such a way though I wouldn't claim
> > it was easy to do.
> 
> There won't be anything significant in Ada 2020; we're too close to the end 
> game for that to be able to do the experimentation with different designs 
> that is still needed. We have a few proposals for "smarter" access type, but 
> no one would call them "more relaxed". The basic idea is to use additional 
> compile-time and run-time restrictions to allow automatic deallocation and 
> to eliminate the possibility of dangling references.
That would be nice.   I think the biggest hurdle to named access types for
me is that the object has to live as long as the access type.  That forces
you into using the equivalent of global variables a lot of time.  At least
in Ada they have separate scopes to help with naming clashes, but it doesn't
protect you from having someone misuse a variable outside of its intent.
> 
> I'm pretty sure there never will be "more relaxed" access types, as there is 
> a substantial community within Ada that would never allow making Ada 
> features less safe (that is, having more erroneous cases). I suppose one 
> could call a named access type that using only dynamic accessibility checks 
> "more relaxed", but all that would do is add a lot of overhead to access 
> types in order to convert a compile-time check into a runtime one (read new 
> way to have a program fail).
More relaxed doesn't necessarily mean less safe.  It can even be more safe.
The less relaxed Ada paradigm can force you to provide a variable outside
of a scope that it is intended to be used in, which is a maintenance hazard.


> 
> P.S. I agree with Dmitry that in many of these cases you don't want to use 
> access types at all. Most ADT interfaces are better off taking the ADT 
> objects directly; leave the client to organizing structures. When you use 
> access types in the interface, you force all clients to use access types in 
> their usage; it's better to let them decide whether scoping, containers, or 
> access types are the best way to manage the objects. (Definitely the most 
> reusable.) (And no, I don't consider forcing clients to use 
> 'Unchecked_Access all over the place as a way for them to avoid using access 
> types.)

I don't like using access types at all, but Ada requires it sometimes.  Just
making a cursor or iterator to a custom container requires it.  And if your
type is not limited, you start getting pushed more into unchecked_access
since you don't have handy tricks like the Rosen Technique.  Conversely,
if you need to keep an array of dispatchable limited types, you have to use
access types (indefinite containers doesn't work on limited types).  I 
don't like to use them in public interfaces at all, so I avoid that, but it
is hard to avoid in implementation and harder still to ensure it is done
right.  My hope is Ada eventually makes that both safe and more maintenance 
friendly in the future, for the times where you have to use them.

Note, I am not saying that Ada has any serious problems, but am just
wishing there was better support for using access types with non heap
objects (for the times that you have to).