Re: Getting the index for an element in mutually referencing containers

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oa70rj$12td$1@gioia.aioe.org...
> On 2017-03-13 20:55, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:oa41a4$1ko5$1@gioia.aioe.org...
>>> On 2017-03-12 17:44, Simon Wright wrote:
>> ...
>>> P.S. It is a pity that Implicit_Dereference type does not have proper
>>> interface to work with *any* type instead of discriminated records. This
>>> is design fault when the use case #2 was taken for #1.
>>
>> It works with any type, since the real target type is the thing 
>> designated
>> by the discriminant. The discriminant is the key, because it is the only 
>> way
>> in Ada to get an access type with a controlled lifetime. The 
>> discriminated
>> type is just a helper, not the end result.
>
> That would be the case #1 with *no* helper type whatsoever:
>
>    type Element ...
>    type Index ...
>    type Container ...
>    function Get (X : Container; I : Index) return Element;
>    for Container'Get_Element use Get;
>
>    function Get (X : Container; I : Index) return access Element;
>    for Container'Access_Element use Get;
>
>    etc

The second case here doesn't limit the lifetime of the return access type, 
and provides no notification when the caller is finally finished with the 
accesss value (which is critical). Don't see how that solves anything for 
"case 1".

>> Yes, we could have done that some other way,
>
> There is no other way, there is another use case #2, when a reference 
> object is required to live longer.

We were not trying to solve that problem, it's relatively easy to solve with 
the existing features (as your reference counted library shows). Ada is 
about building blocks, not necessarily polished solutions.

...>> and indeed we started with a
>> separate construct, but the semantics ended up identical to that of an
>> access discriminant of a controlled type -- so why build another 
>> construct
>> (with all of the additional chances of getting it wrong) when an existing
>> one will do?
>
> Because it gets everything wrong in the major use case #2.

Which it was not intended to solve. The whole "strong/weak reference" 
business is not fundemental to solving problems -- if anything, it gets in 
the way. We were only trying to solve the problem of having a reference that 
is still safe (in the sense that the underlying data can be protected from 
destruction while the reference exists). That requires two things: having a 
reference that can't be copied, and having a call-back possibility when the 
reference goes away. The Ada 2012 reference mechanism provides both.

We looked at more complex schemes and they mostly added confusion and 
complexity rather than any benefit. If you want strong and weak references, 
it's easy enough to build them from the parts available.

                                    Randy.