!standard 6.1.1(26/3) 12-06-06 AI12-0032-1/01 !standard 6.1.1(27/3) !class binding interpretation 12-06-06 !status work item 12-06-06 !status received 12-05-29 !priority Low !difficulty Medium !subject 'Old and accessibility !summary (1) The accessibility level of X'Old is that of the associated implied constant declaration. (2) If X has an anonymous access type, the implied constant associated with X'Old has an anonymous access type with the same designated type or profile. !question 1) X'Old denotes a (constant) object. The accessibility level of that object does not seem to be defined by the current wording of the Standard. Should it be? (It's OK as is.) 2) X and X'Old are defined to have the same type, even if that type is anonymous. That's usually good. We want to allow: Table : array (1 .. 3) of Integer; procedure Foo with Post (Table = Table'Old); If, however, X is of an anonymous access type, then things get odd. What does it mean to say that a standalone constant has the same type as, say, an access discriminant? This makes no sense. Even if X itself is a standalone object, having two such objects sharing the same type leads to problems (for example, does the accessibility level of the type of X'Old then depend on the value most recently assigned to X?). Should we define the type of the constant to be an anonymous access with the same designated type? (Yes.) !response Neither of these problems are worth complicating the wording. For (1), we believe that the existing model is sufficient; after all, we already say that the finalization point (which is determined by the master, which determines accessibility, after all) is determine by the location of the implicit constant. So an additional AARM note is sufficient. For (2), complicating the wording doesn't seem to add much; hardly anyone will think about the ramifications of having the type be "the same" rather than a new anonymous access type. Users will expect to work as if they had written it by hand, and it will. So we simply add a To Be Honest note to clarify that there is a special case here not implied by the formal wording. !wording Add to AARM 6.1.1(27.d/3): "If the accessibility of X'Old is needed (for example, if 'Access of an aliased component of X'Old is taken), the accessibility is determined as implied by the implicit constant declaration." Add after AARM 6.1.1(27.f/3): "AARM To Be Honest: If the type of X is an anonymous access type, the type of the implicit constant declaration is anonymous access type with the same designated type or profile as X. This is necessary as the constant needs to follow the rules for an object of an anonymous access type and not the rules for whatever X is (it might be an access parameter or access discriminant). Thus the type is not exactly the same, rather it would be what would be written if you declared X_Old explicitly. It didn't seem worth the complications to explain this in the normative wording; no one would expect anything else." !discussion None needed. !ACATS test Create an ACATS C-Test to check that the accessibility of X'Old is as implied by these (implied) rules. !appendix From: Steve Baird Sent: Tuesday, May 29, 2012 2:26 PM 1) X'Old denotes a (constant) object. I don't believe the accessibility level of that object is defined by the current RM wording, although the intent seems clear. Not a big deal, but I think some wording is missing here. 2) X and X'Old are defined to have the same type, even if that type is anonymous. That's usually good. We want (I think) to allow Table : array (1 .. 3) of Integer; procedure Foo with Post (Table = Table'Old); If, however, X is of an anonymous access type, then things get odd. What does it mean to say that a standalone constant has the same type as, say, an access discriminant? This makes no sense. Even if X itself is a standalone object, having two such objects sharing the same type leads to problems (e.g., does the accessibility level of the type of X'Old then depend on the value most recently assigned to X?). I see two choices: A) Disallow X'Old if X is of an anonymous access type. B) If X is of an anonymous access type, define X'Old to be a standalone constant of an anonymous access type having the same designated subtype as the type of X. X'Old then follows the usual accessibility rules for such a constant. Opinions? **************************************************************** From: Bob Duff Sent: Tuesday, May 29, 2012 2:36 PM > 1) X'Old denotes a (constant) object. I don't believe the > accessibility level of that object is > defined by the current RM wording, although > the intent seems clear. Not a big deal, but > I think some wording is missing here. Isn't that covered by saying where the object is declared? > 2) X and X'Old are defined to have the same type, > even if that type is anonymous. > > That's usually good. We want (I think) to allow > > Table : array (1 .. 3) of Integer; > > procedure Foo > with Post (Table = Table'Old); > > If, however, X is of an anonymous access type, > then things get odd. What does it mean to say that > a standalone constant has the same type as, say, > an access discriminant? This makes no sense. Agreed. > Even if X itself is a standalone object, having > two such objects sharing the same type leads to > problems (e.g., does the accessibility level of the > type of X'Old then depend on the value most recently > assigned to X?). > > I see two choices: > A) Disallow X'Old if X is of an anonymous access type. > B) If X is of an anonymous access type, define X'Old > to be a standalone constant of an anonymous access > type having the same designated subtype as the type > of X. X'Old then follows the usual accessibility rules > for such a constant. > > Opinions? B), I think. A) seems like an arbitrary restriction related to arcane language-lawyerly mumbo jumbo that could never be explained to normal programmers. B) is what you'd get if you just wrote the code by hand in the natural way. **************************************************************** From: Ed Schonberg Sent: Tuesday, May 29, 2012 2:44 PM > I see two choices: > A) Disallow X'Old if X is of an anonymous access type. > B) If X is of an anonymous access type, define X'Old > to be a standalone constant of an anonymous access > type having the same designated subtype as the type > of X. X'Old then follows the usual accessibility rules > for such a constant. > > Opinions? B) seems preferable. It is what a user would intuitively expect, and it does not require yet another exception to some RM rule. **************************************************************** From: Steve Baird Sent: Tuesday, May 29, 2012 3:08 PM >> 1) X'Old denotes a (constant) object. I don't believe the >> accessibility level of that object is >> defined by the current RM wording, although >> the intent seems clear. Not a big deal, but >> I think some wording is missing here. > > Isn't that covered by saying where the object is declared? > Maybe you are right. We did decide that we wanted an AARM note about finalization (6.1.1(27.d)) in what seems like an analogous situation. Maybe that is all we need here (or perhaps not even that). Speaking very (probably excessively) strictly, all we have is The value of X'Old in the postcondition expression is the value of this constant; the type of X'Old is the type of X. as opposed to something like X'Old is a name that denotes this constant. , which would clearly settle the issue. If folks think no changes are needed here, I'm ok with that. >> Opinions? > > B), I think. > > A) seems like an arbitrary restriction related to arcane > language-lawyerly mumbo jumbo that could never be explained to normal > programmers. > > B) is what you'd get if you just wrote the code by hand in the natural > way. I agree. I think the best argument for A over B is an assertion that this is a totally unimportant case that nobody cares about; yes, it should be well-defined, but nobody cares what that definition is. Choice A requires less RM wording, so let's go with that. But as you point out, choice B is more regular even if it requires more RM wording. Choice A only makes sense if this is a case we don't care about; if we don't care about it, then why would we want to introduce a special-case rule for it? **************************************************************** From: Tucker Taft Sent: Tuesday, May 29, 2012 3:34 PM I agree with the others that we want to allow references to objects of an anonymous access type. In most cases these are constants anyway, but in the rare case where they might change, I can't imagine justifying a restriction against referring to their 'Old value. A "TBH" rule sounds just about right. No one other than an implementor could even imagine there is a problem. **************************************************************** From: Randy Brukardt Sent: Wednesday, June 6, 2012 10:46 PM You're right. But your last sentence is way too broad. It should read: "No one other than Steve Baird (and maybe Adam Beneschan) could even imagine there is a problem." ;-) ****************************************************************