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!news.fcku.it!news.uzoreto.com!news.etla.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.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: two questions on allocators Date: Fri, 2 Mar 2018 16:31:17 -0600 Organization: JSA Research & Innovation Message-ID: References: <93229821-ae3d-4e47-91d9-a20ff3c1f1a7@googlegroups.com><55fda761-55f8-4b25-b8ab-0125acf16b05@googlegroups.com> Injection-Date: Fri, 2 Mar 2018 22:31:18 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="10107"; 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:50801 Date: 2018-03-02T16:31:17-06:00 List-Id: "Robert A Duff" wrote in message news:wcctvtzqtb1.fsf@TheWorld.com... > "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... No, that wording seems wrong. Shouldn't it say "if any subcomponents are initialized by default" or something like that? (That is, if the subcomponents have defined values.) As it stands, an object initialized by a Default_Value aspect (and access types work like that as well) is not rechecked. The rule as it stands means that you have allocated objects that violate their predicate. That doesn't seem to be a good thing. I believe the purpose of the rule is avoid checking objects that are completely uninitialized (as the result would be random), but there is no reason to avoid making the check when the object is initialized-by-default. >> 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. ??? The only cases where this works is when the object is declared such that it violates the predicate and the predicate is NOT checked. An object that violates a predicate is a bug, regardless of whether or not it is checked. So all this does is hides the detection of a bug -- I can't see any advantage to that. If you later use the object without a null check (as should be expected), you are going to have a problem. One reason *not* to use Dynamic_Predicates if an alternative is available is because they allow bugs like this. The rule mentioned above needs to be fixed *at least* for Static_Predicates, since they are intended to be equivalent to constraints, and a constraint would not allow such a situation. > 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", as a subtype property, lets the compiler omit access_checks from the code. It's possible that the predicate would let the checks be optimized away, but that is not a certainty. > Not null? Not! ;-) So you don't use ranges, either? ;-) Randy.