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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Q: access to subprogram Date: 1996/07/03 Message-ID: #1/1 X-Deja-AN: 163553013 references: <4rb9dp$qe6@news1.delphi.com> <4rd5lu$q4@mulga.cs.mu.OZ.AU> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-03T00:00:00+00:00 List-Id: Bob Duff said "Now, GNAT has gone and provided the same capability, using an implementation-defined attribute (Unrestricted_Access), but unfortunately, this attribute allows dangling pointers to subprograms, unlike either of the above options." But unfortunately, virtually all the useful uses of Unrestricted_Access, at least in my experience are cases where your limited mechanisms would have been insufficient, since we definitely need to be able to assign these values. So we would probably have put the attribute in even if the language had the safe cases. Note that the two safe cases that Bob mentions are in fact cases where the work arounds required in the current language are pretty straightforward, so the limited form of the feature proposed in Bob's note is not very convincing since it provides rather limited capabilities and no significant increase in expressive power.