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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: two questions on allocators Date: Thu, 1 Mar 2018 09:30:55 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <93229821-ae3d-4e47-91d9-a20ff3c1f1a7@googlegroups.com> <55fda761-55f8-4b25-b8ab-0125acf16b05@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:50737 Date: 2018-03-01T09:30:55+01:00 List-Id: On 01/03/2018 00:37, Randy Brukardt wrote: > "Robert A Duff" wrote in message > news:wcczi3t6qqh.fsf@TheWorld.com... >> Mehdi Saada <00120260a@gmail.com> writes: >> >>> I saw that since I (tried to) read the AARM, but didn't really got >>> it. Now it's ok. If the problem of these null forbidding hypothetic >>> subtypes is that can't have the default null value, why not just require >>> the user to give one ? >> >> Don't use "not null"; it's broken as you see. Instead, do: >> >> subtype S is T with Predicate => S /= null; > > ??? You'd get the same problem with the allocators (that they always raise > an exception) with this formulation. > > If you did want a subtype to use for an initialized allocator (which the OP > specifically wasn't using), then > > subtype S is not null T; > > works just fine. And this at least is guaranteed to be checked everywhere > necessary, that's not true for a Dynamic_Predicate (as you know). > > Probably in most cases, they are equivalent, but when they are not > equivalent, it is just because you have pushed static checks to runtime, > which hardly seems to be an advantage. True. Dynamic checks is evil unless a contract. The contract "raise Constraint_Error if null" is already there, which makes all exercise pointless. --- As I keep on repeating: constructors, they must be here. There is no way to work that fundamental block around. Otherwise we will always be running into the same problem that any assignment has a left side, which must be come from somewhere and be conform with all constraints including ones of the right side. There is nothing wrong with "not null access" except for lack of constructors in Ada. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de