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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:7c04:: with SMTP id a4mr3431481itd.143.1553376746196; Sat, 23 Mar 2019 14:32:26 -0700 (PDT) X-Received: by 2002:a9d:30d2:: with SMTP id r18mr12475946otg.176.1553376746064; Sat, 23 Mar 2019 14:32:26 -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!w126no333340ita.0!news-out.google.com!r82ni91ita.0!nntp.google.com!78no334242itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 23 Mar 2019 14:32:25 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.109.61.2; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 70.109.61.2 References: <6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com> <6f9ea847-2903-48c8-9afc-930201f2765a@googlegroups.com> <94a74b21-9c35-4f90-90f8-6262cde49e20@googlegroups.com> <0e27ab0a-5daa-45b0-ae5c-a2441fb1ad40@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <469bcfa0-30d2-4f54-ba5e-dd21e5a338e5@googlegroups.com> Subject: Re: Intervention needed? From: Jere Injection-Date: Sat, 23 Mar 2019 21:32:26 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:55943 Date: 2019-03-23T14:32:25-07:00 List-Id: On Saturday, March 23, 2019 at 4:03:15 AM UTC-4, Randy Brukardt wrote: > The classic (and rare) example of a limited type is one containing a task. > For those, you do need to control initialization. You also need to do so if > the type has any discriminants. > > I suppose it would be possible to do in a sense by defining *exactly* what > every operation must do (essentially by providing the body) -- but then > there is no reason to standardize it, because there is no value to be added > by an implementer. (Anyone can download a library from github or whatever > and compile with with whatever compiler you want.) > > This is the same sort of reason it doesn't make much sense to allow > user-defined storage pools in a container -- you would have to precisely > define what allocators are going to do (in terms of allocation sizes, > ordering, and the like) so that a pool could take advantage of that. But > then there's really nothing for the implementation to do - the package is so > heavily specified that there is no freedom to improve the implementation. > > Randy. > I really just wish that Ada would find a way to close those remaining holes. I've had the discussion before with others about access types, but it is hard to make the argument to others that in Ada you don't have to use Access types, when the reality is that is only mostly true. I would like to get to a point where the only time I need to use unchecked_deallocation in my own code, is when I have to do something for performance reasons. Even if that is simply some sort of smart access wrappers provided by the standard that work for limited types. I feel like something as basic as memory deallocation should have more automatic coverage options in the language.