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

["Randy Brukardt" <randy@rrsoftware.com>]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:252afc47-fe7d-41bc-b394-0735e1fd2e4c@googlegroups.com...
...
> 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.

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

For most other uses, the best thing to do with accessibility checks is turn 
them off. You have to dynamically manage lifetime in that case (usually 
using a controlled type to do it), and accessibility provides nothing in 
that case. And you turn off accessibility checks by using 'Unchecked_Access.

For the most part, I personally view accessibility checks as a mistake, but 
then again I never write programs in the first category. So I have to take 
others word for it that it is useful there. Dynamic accessibility provides 
nothing but overhead and tripping hazards (the possibility of a mysterious 
exception in otherwise tested code).

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

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

I'd like to see a way to allow named access types to have the various 
special behaviors associated only with anonymous access types today, but I 
certainly would not characterize that as "more relaxed".

                                          Randy.

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