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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Access parameters and accessibility Date: Tue, 16 Dec 2014 14:47:25 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1418762846 28930 24.196.82.226 (16 Dec 2014 20:47:26 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 16 Dec 2014 20:47:26 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24058 Date: 2014-12-16T14:47:25-06:00 List-Id: wrote in message news:alpine.DEB.2.11.1412160940270.7909@debian... On Tue, 16 Dec 2014, Randy Brukardt wrote: >> Indeed, no Ada compiler has ever actually implemented correct >> accessibility checking for Ada 2005 or later. > >Could you envision the ARG to drop anonymous access parameters, or at >least severely restrict their usage, in the next language revision? > >If a language feature has not yet been properly implemented, you don't >break working code by dropping this feature. No, because what's broken isn't really relevant to the proper use of the feature. Typically, it just means that Program_Error isn't raised in some cases in which it should be -- but those cases aren't very likely to occur in practice anyway. What we've actually talked about is giving up on these checks and just letting misuse be erroneous. Most people don't want to go there if we don't have to, but since we already go there for Unchecked_Deallocation, we're already there. Proper dangling pointer checks would be too expensive, sadly (especially for non-allocated objects). And of course the compatibility cost would be significant. We might consider some additional restrictions (on the line of "No_Coextensions" and "No_Anonymous_Allocators", see H.4), but I think that is as far as we could go. Randy.