From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!2.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!cleanfeed1-b.proxad.net!nnrp3-2.free.fr!not-for-mail From: Thomas Newsgroups: comp.lang.ada Mail-Copies-To: nobody Subject: Re: Unchecked_Deallocation with tagged types References: <607b56f8$0$3721$426a34cc@news.free.fr> <07863309-4541-4497-8cec-d88179e634bdn@googlegroups.com> <3d6e49b6-f195-4dc2-bf4b-795f18f2da9dn@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Mon, 18 Apr 2022 07:51:29 +0200 Message-ID: <625cfc61$0$22069$426a34cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 18 Apr 2022 07:51:29 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1650261089 news-4.free.fr 22069 91.175.52.121:6031 X-Complaints-To: abuse@proxad.net Xref: reader02.eternal-september.org comp.lang.ada:63749 List-Id: In article , "Dmitry A. Kazakov" wrote: > On 2021-04-20 20:53, Randy Brukardt wrote: > > > OTOH, an Ada > > follow-on would most likely have access types with automatic deallocation as > > proposed by Tucker in one of the many AIs on ownership. who is Tucker, and where can i read him, please? :-) > > So using any form of > > explicit deallocation would be discouraged (as would the use of raw pointer > > types). > > I do not understand how that could work, it sounds like a halting > problem to me, i feel that: 1) afaik, non-pool-specific access-to-variable types, which should point on aliased objects, are not dangerous, as long as neither new nor Unchecked_Deallocation are used. 2) pool-specific access-to-variable types should mostly look like Ada.Containers.Indefinite_Holders. there is missing one for definite limited types, and i hope it's possible to also make it for indefinite limited types (if it's not allowed in Ada, it should be planned for an Ada follow-on). > but anyway, where is a problem? Add a whole new hierarchy > of access types independent on the existing one. anyway, we can begin to think about it, and see later what it should become. but if Tucker already begun to think about it, i would prefer read him before develop my own think, to avoid redo what he already did :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/