From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 2002:a6b:19c1:: with SMTP id
 184-v6mr9787396ioz.66.1533654783527;
        Tue, 07 Aug 2018 08:13:03 -0700 (PDT)
X-Received: by 2002:aca:75c9:: with SMTP id
 q192-v6mr573991oic.3.1533654783395;
 Tue, 07 Aug 2018 08:13:03 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!1.eu.feeder.erje.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.68.MISMATCH!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!g13-v6no637101itf.0!news-out.google.com!k71-v6ni1055itk.0!nntp.google.com!g13-v6no637096itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 7 Aug 2018 08:13:03 -0700 (PDT)
In-Reply-To: <pkafj7$5tg$1@franka.jacob-sparre.dk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=47.185.195.62;
 posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo
NNTP-Posting-Host: 47.185.195.62
References: <pjvpmk$u33$2@franka.jacob-sparre.dk>
 <dc0f1491-0e8c-43c5-a78f-e32d59df5f03@googlegroups.com>
 <pk2fiq$2nq$1@franka.jacob-sparre.dk>
 <cc25c794-5986-4f6e-9d5e-0ec20a4f47d0@googlegroups.com>
 <pkafj7$5tg$1@franka.jacob-sparre.dk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <62cefa64-4855-4d51-9216-519f260349d4@googlegroups.com>
Subject: Re: Visibility of Indexing aspects
From: "Dan'l Miller" <optikos@verizon.net>
Injection-Date: Tue, 07 Aug 2018 15:13:03 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3289
X-Received-Body-CRC: 229647304
Xref: reader02.eternal-september.org comp.lang.ada:54084
Date: 2018-08-07T08:13:03-07:00
List-Id: <comp.lang.ada>

On Monday, August 6, 2018 at 4:46:16 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:cc25c794-5986-4f6e-9d5e-0ec20a4f47d0@googlegroups.com...
> ...
> >Ummmmmmmmm, what is so incredibly "expensive" about Element => 
> >Self.Data(Index)'Access in OP?
> 
> Nothing is expensive about *that*, but it's also very unsafe by itself (this 
> either prevents a container from ever reusuing memory, or essentially 
> requires being OK with dangling pointers and the erroneousness that they 
> cause).
> 
> Our requirement was that the user-defined dereference mechanism needs to be 
> safe (at least possible to be safe), and that requires the container to be 
> able to find out when the dereference ceases to exist. At that point, the 
> container can free the underlying memory if need be. (For an extreme 
> example, consider a persistent container, where the object only should exist 
> in memory so long as it is being used there.) The design that we came up 
> with for Ada 2012 uses finalization for this notification; we looked at 
> other mechanisms, but they would have had similar overhead.
> 
> The Ada containers use the finalization to clear the tampering check (which 
> prevents deleting of elements while the dereference exists); other uses are 
> possible, of course.
> 
> Without these sorts of checks, Ada containers would be no more safe than C 
> code. In particular, Ada programmers do not expect checked indexing to be 
> unsafe, so syntax of C(I) being unsafe would be a particular surprise.
> 
>                                     Randy.

My reference-counting of aliases in my reply above concurs with what you saying in this reply of yours.

Randy, you make a strong argument for the compiler/language tracking the lifetime of aliases instead of leaving it as a library and/or app-domain responsibility.