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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: GNAT GPL 2013 bug? Date: Mon, 12 Aug 2013 20:34:00 +0200 Organization: cbb software GmbH Message-ID: <1sjqnkpq64coc$.1xmhu8h9q4qua$.dlg@40tude.net> References: <19fr4wmxmen$.gjbias2fj461$.dlg@40tude.net> <1pe6z4dg2xk9j$.1wdn31ijaldz3.dlg@40tude.net> <4589f4c3-a1c7-4fa7-9b79-89a9917502bf@googlegroups.com> <1evw1coxfrfu5$.1atfpln47qs0j.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: RXJ+FkxPc8/mFTAaIGiJWQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:16831 Date: 2013-08-12T20:34:00+02:00 List-Id: On Mon, 12 Aug 2013 10:20:05 -0700 (PDT), Adam Beneschan wrote: > On Monday, August 12, 2013 10:03:14 AM UTC-7, Dmitry A. Kazakov wrote: > >> That implied null-exclusion for controlling parameters does not change/save >> anything. Just added language weirdness that >> >> "access T" is subtype conformant to "not null access T" depending on T >> >> !, for apparently no gain. > > Well, from the point of view of dynamic semantics, a call to a dispatching > subprogram *has* to fail if given a null parameter. A dispatching call, you mean, and not fail, but propagate Constraint_Error. And that does not imply that a non-dispatching call have to. Semantically they are different. > There's no way around this. Actually there is one. Access type is a by-value type. As such it could have non-tagged classes, using the standard scheme: T -> Value T'Class -> (T'Tag, Value) So null access T'Class would become (T'Tag, null) rather than bare null. Which would make it possible to dispatch on it without assuming that the target body is always (begin raise Constraint_Error; end). Not that dispatching on null would be terribly useful, of course... > So, dynamically, it's going to behave like a null-excluding access > type no matter what. Yes, though, as I said, it is because of access T'Class. It is not because there is something wrong with access T. Smoke and mirrors. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de