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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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

> 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. That should be *any* type:

    type Reference_Type is private;
private
    function Get (X : Reference_Type) return access Element;
    for Reference_Type'Implicit_Conversion (Element) use Get;

of course it should be inheritance from Element in a better world:

    type Reference_Type is new Element;
private
    function To_Element (X : Reference_Type) return Element;
    for Reference_Type'Upcast_Conversion use To_Element;

by reference:

    type Reference_Type is new access Element;
private
    function To_Element (X : Reference_Type) return access Element;
    for Reference_Type'Upcast_Conversion use To_Element;


> 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. You need 
invalidated reference types. A pointer when explicit cannot be 
discriminant and furthermore there might be a pool-specific pointer or 
no pointer at all. And nobody wants to expose pointers under no 
circumstances anyway. When pointers are exposed any shred of safety is gone.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de