!standard 3.5(55/3) 14-11-14 AI12-0124-1/03 !class binding interpretation 14-10-19 !status Corrigendum 2015 14-11-14 !status ARG Approved 7-0-1 14-10-19 !status work item 14-08-11 !status received 14-08-08 !priority Low !difficulty Easy !subject Add Object'Image !summary Allow the prefix of the Image attribute to be an object. !question GNAT has the attribute Obj'Img, which is very useful for debugging and testing as it does not require looking up the name of the subtype of Obj. This is commonly used in GNAT programs. Should standard Ada should have something similar? (Yes.) !recommendation (See Wording.) !wording For a prefix X that denotes an object of a scalar type [(after any implicit dereference)], the following attributes are defined: X'Wide_Wide_Image X'Wide_Wide_Image denotes the result of calling function S'Wide_Wide_Image with /Arg/ being X, where S is the nominal subtype of X. X'Wide_Image X'Wide_Image denotes the result of calling function S'Image with /Arg/ being X, where S is the nominal subtype of X. X'Image X'Image denotes the result of calling function S'Image with /Arg/ being X, where S is the nominal subtype of X. !discussion We use an overloading of the existing attribute Image rather than following GNAT's lead of Img. Our understanding is that GNAT used Img rather than Image simply because 4.1.4(12/1) requires that implementation-defined attributes have different names than language-defined ones. Moreover, Ada generally does not use abbreviations, and this abbreviation would only save two characters. This addition is compatible, as subtypes do not allow overloading. Thus, if an object X hides a subtype X, X'Image is currently illegal (and this would be a straight extension). If a subtype X hides an object X, no change would occur. This should be implementable relatively easily, as the Size attribute already allows both subtypes and objects as the prefix, so there is a similar attribute to use as a model. Note that the prefix of an attribute has to be a name, but any expression can be wrapped in a qualification or type conversion in order to make it a name. (Of course, in that case, the advantage of not having to know the subtype name has disappeared.) !corrigendum 3.5(55/3) @dinsa @xindent of type String is equivalent to a call on S'Wide_Wide_Value for a corresponding @i of type Wide_Wide_String.> @dinss For a @fa X that denotes an object of a scalar type (after any implicit dereference), the following attributes are defined: @xhang<@xterm X'Wide_Wide_Image denotes the result of calling function S'Wide_Wide_Image with @i being X, where S is the nominal subtype of X.> @xhang<@xterm X'Wide_Image denotes the result of calling function S'Wide_Image with @i being X, where S is the nominal subtype of X.> @xhang<@xterm X'Image denotes the result of calling function S'Image with @i being X, where S is the nominal subtype of X.> !ASIS No ASIS impact(??). (The attribute name already exists, so it is in the appropriate enumeration. ASIS does not have separate rules for individual attributes (if it did, the ones for Image would require change). !ACATS test An ACATS C-Test is needed to verify that the attributes are implemented as specified. !appendix From: Randy Brukardt Sent: Friday, November 14, 2014 8:38 PM At the meeting, we discussed where to put these new definitions in 3.5. The minutes say we decided: Put each after the matching subtype version. Unfortunately, this makes no sense. The subtype attributes are all under a lead-in heading that says: For every scalar subtype S, the following attributes are defined: (It's way up at 3.5(11), it's easy to miss given that there are more than 60 paragraphs under that heading.) The new attributes will have to be under a heading: For a prefix X that denotes an object of a scalar type, the following attributes are defined: We could of course duplicate the headings all over the place, but that doesn't make much sense. Thus, the only place to put these that makes sense is at the end of the existing list (after 3.5(55/3)). I'm just going to do that, but since I'm ignoring an explicit decision of the group, I wanted to put on the record why I did that. **************************************************************** From: Jeffery Cousins Sent: Saturday, November 15, 2014 2:46 AM Thanks for spotting that that Randy. I'm surprised that we don't already have much on attributes of objects, 4.1.4 allows them. Where do we say that you can have `First and `Last on objects of an array type? 3.6.2 only has them for array types, not objects of an array type. **************************************************************** From: Randy Brukardt Sent: Saturday, November 15, 2014 8:38 PM No, 3.6.2 says: The following attributes are defined for a prefix A that is of an array type [(after any implicit dereference)], or denotes a constrained array subtype: "OF an array type"; "object" is implicit here. Note that the subtype case is mentioned second. And there surely isn't any implicit dereference of a subtype. We can't share the attribute definitions here in 3.5 like is done in 3.6.2, because we need to talk about the argument in the X'Image case. I got the wording I used from X'Valid (and the letter of the prefix, too). I left out the part about "(after any implicit dereference)", because it seems to go without saying, but perhaps I should add it in to be consistent with other object attributes. **************************************************************** From: Tucker Taft Sent: Saturday, November 15, 2014 12:43 PM > ... I'm just going to do that, but since I'm ignoring an explicit > decision of the group, I wanted to put on the record why I did that. Your approach makes sense to me. I would hope the semantics could be described by transformation, rather than by repeating them in all their gory details. **************************************************************** From: Randy Brukardt Sent: Saturday, November 15, 2014 8:33 PM The wording we agreed on in Portland was: X'Image X'Image denotes the result of calling function S'Image with Arg being X, where S is the nominal subtype of X. And I didn't change that, just where it was located. **************************************************************** From: Robert Dewar Sent: Sunday, November 16, 2014 5:38 AM > X'Image > X'Image denotes the result of calling function S'Image with Arg > being X, where S is the nominal subtype of X. That's nice, would have avoided introducing the annoying 'Img in GNAT. Is this a retroactive change? Sometimes I wonder whether it was a good idea to allow implementations freely to introduce new attributes (which in any case are non-portable) but not to extend existing attributes. **************************************************************** From: Randy Brukardt Sent: Monday, November 17, 2014 11:34 PM > That's nice, would have avoided introducing the annoying 'Img in GNAT. > Is this a retroactive change? Of course, it's the annoying 'Img that gave us the idea for this change. Without the practice, we surely would never have approved it (some of the group found it ugly, but the fact that it has proven highly convenient in practice trumps such concerns). And, yes, it's a Binding Interpretation that will be in the upcoming Corrigendum, so it will be considered part of Ada 2012 (just like raise_expression and aspect Predicate_Failure). We're not really allowed to talk about previous versions of Ada, so we can't add it to Ada 95 or Ada 2005. **************************************************************** From: Robert Dewar Sent: Tuesday, November 18, 2014 2:50 AM Probably in GNAT we may just add it to 2012 mode, for previous modes you have to be careful about introducing new attributes that will be incompatible with other implementations (pragmas are not a problem, but attributes are). On the other hand, we do allow 'Img in these modes, hmmm, to think about. ****************************************************************