!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, 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<For the evaluation of a call on S'Value for an enumeration subtype
S, if the sequence of characters of the parameter (ignoring leading and
trailing spaces) has the syntax of an enumeration literal and if it corresponds
to a literal of the type of S (or corresponds to the result of S'Image for a
value of the type), the result is the corresponding enumeration value;
otherwise, Constraint_Error is raised. For a numeric subtype S, the evaluation
of a call on S'Value with @i<Arg> of type String is equivalent to a call on
S'Wide_Wide_Value for a corresponding @i<Arg> of type Wide_Wide_String.>
@dinss
For a @fa<prefix> X that denotes an object of a scalar type, the following
attributes are defined: 
@xhang<@xterm<X'Wide_Wide_Image>
X'Wide_Wide_Image denotes the result of calling function
S'Wide_Wide_Image with @i<Arg> being X, where S is the nominal
subtype of X.>
@xhang<@xterm<X'Wide_Image>
X'Wide_Image denotes the result of calling function S'Wide_Image
with @i<Arg> being X, where S is the nominal subtype of X.>
@xhang<@xterm<X'Image>
X'Image denotes the result of calling function S'Image with @i<Arg>
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.

****************************************************************