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!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Visibility of Indexing aspects Date: Tue, 7 Aug 2018 17:41:57 -0500 Organization: JSA Research & Innovation Message-ID: References: <62cefa64-4855-4d51-9216-519f260349d4@googlegroups.com> Injection-Date: Tue, 7 Aug 2018 22:41:58 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="17661"; mail-complaints-to="news@jacob-sparre.dk" 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.7246 Xref: reader02.eternal-september.org comp.lang.ada:54090 Date: 2018-08-07T17:41:57-05:00 List-Id: "Dan'l Miller" wrote in message news:62cefa64-4855-4d51-9216-519f260349d4@googlegroups.com... ... > 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. Programming language research seems to be moving toward compile-time rules preventing the need for lifetime tracking. One things we've considered (not seriously this go-around) is compile-time locking (essentially compile-time tampering checks, to use the Ada 2012 container terminology). Then there is no runtime overhead and no time-bomb from occassionally failing runtime checks. It mostly can be defined in terms of the Global aspect (as defined in Ada 2020), although it would be a rather big stick (lots of legit. stuff would also be prevented). Randy.