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:a24:3552:: with SMTP id k79mr1266592ita.18.1552961933328; Mon, 18 Mar 2019 19:18:53 -0700 (PDT) X-Received: by 2002:a9d:2c28:: with SMTP id f37mr33696otb.126.1552961933108; Mon, 18 Mar 2019 19:18:53 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!82no71146itk.0!news-out.google.com!y88ni77ita.0!nntp.google.com!78no70736itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 18 Mar 2019 19:18:52 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.255.209.31; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 96.255.209.31 References: <6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6f9ea847-2903-48c8-9afc-930201f2765a@googlegroups.com> Subject: Re: Intervention needed? From: Optikos Injection-Date: Tue, 19 Mar 2019 02:18:53 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55894 Date: 2019-03-18T19:18:52-07:00 List-Id: On Monday, March 18, 2019 at 7:36:17 PM UTC-4, Randy Brukardt wrote: > "Optikos" wrote in message=20 > news:6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com... > On Tuesday, March 12, 2019 at 5:53:04 PM UTC-4, Randy Brukardt wrote: > >ARG, please leave an immense paper trail of what-conflicts-with-what in > >Ada as defined to achieve a Rust-esque borrow checker in its full=20 > >perfect-pointer form. >=20 > Read the proposals for AI12-0240-1 through AI12-0240-5. The main problem = is=20 > massive amounts of complexity. >=20 > >Randy, would Tucker's new ownership proposal come close to 100%=20 > >feature-parity > >with Rust's borrow checker? > ... > since the containers are designed with possibly dangling cursors, a total= ly=20 > safe system would not be usable with them. The containers do include chec= ks=20 > that would detect many ownership problems, however, so any lack of=20 > compile-time safety is definitely mitigated. (It's not 100% safe because = of=20 > the possiblity that a cursor outlive the owner object; in that case, the= =20 > checks are unreliable.) A container could have (as a required fundamental axiom) a singly-linked li= st of spirits of all cursors ever created that reference it. As each curso= r's life ends, that dying cursor directly knows O(1) where its spirit is wi= thin that linked list, and then removes its dying spirit too. Then as the = lifetime of the container ends, the finalization of that linked list is to = walk that link-list of spirits to abruptly undermine each spirit's correspo= nding still-living cursor so that that longer-lived-than-its-container curs= or abruptly has the usual customary representation of cursor-exhausted-its-= walk-of-the-container (i.e., the end-of-loop criterion during normal-operat= ions' not-end-of-lifed cursor walks of not-end-of-lifed container), so that= cursors are all instantly loop-terminating gracefully whenever their conta= iner ceases to exist. Hence, no cursor ever contains a pointer/access/address value that out live= s its container, because that pointer was overwritten (at container finaliz= ation) with the cursor-exhausted-its-walk-of-the-container reserved value t= hat all loops & conditional branches interrogate as a matter of their norma= l-operations behavior. Q.E.D. Randy, are there any other examples of feared-to-be-dangling pointers outli= ving what they point to in Tucker's latest proposal?