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!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: two questions on allocators Date: Thu, 01 Mar 2018 18:17:54 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <93229821-ae3d-4e47-91d9-a20ff3c1f1a7@googlegroups.com> <55fda761-55f8-4b25-b8ab-0125acf16b05@googlegroups.com> NNTP-Posting-Host: shell02.theworld.com Mime-Version: 1.0 Content-Type: text/plain X-Trace: pcls7.std.com 1519946274 442 192.74.137.72 (1 Mar 2018 23:17:54 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 1 Mar 2018 23:17:54 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:Vkuu0JvpJOGU2WS/AJFYNmqcOMQ= Xref: reader02.eternal-september.org comp.lang.ada:50779 Date: 2018-03-01T18:17:54-05:00 List-Id: "Randy Brukardt" writes: > "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. I'm not sure which example you're talking about. There were several in this thread, and they had enough syntax errors that I don't know what was intended. But I don't think so. 3.2.4(31) says that for an uninitialized allocator, the predicate is checked only if "any subcomponents have default_expressions", which cannot be the case for an access object. Am I missing something? I wrote that wording originally, but it was a long time ago... > 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. "not null" is checked in more places than "Predicate => S /= null". You might think that means "not null" is safer. But the problem with that reasoning is that it means there are cases (as discovered by the OP) where you can't use "not null". So if you have: type Opt_Thing is access Designated; subtype Thing is not null access Opt_Thing; then there will be cases where you have to use Thing instead of Opt_Thing, making the code LESS safe. If you use a predicate, you can use Thing in more cases, and get more checking. I can't think of any case in which "not null" is better than the predicate. Sometimes they are the same, sometimes "not null" is worse; hence my recommendation to not use it. Not null? Not! ;-) - Bob