AI22-0088-1

!standard 4.10(16/5)                                    24-03-14  AI22-0088-1/03

!class binding interpretation 23-12-07

!status Amendment 1-2022  23-12-14

!status WG9 Approved 24-06-10

!status ARG Approved  11-0-0  23-12-14

!status work item 23-12-07

!status received 23-11-29

!submitter Tucker Taft

!priority Low

!difficulty Easy

!qualifier Clarification

!subject Privacy and Put_Image

!summary

For determining whether Put_Image has been directly specified for an ancestor of a type extension, we look in both the visible and private part of the package that defines the ancestor type.

!issue

4.10(16/5) says:

For a nonnull type extension, the default implementation of T'Put_Image depends on whether there exists a noninterface ancestor of T (other than T itself) for which the Put_Image aspect has been directly specified. If so, then T'Put_Image will generate an image based on extension aggregate syntax where the ancestor type of the extension aggregate is the nearest ancestor type whose Put_Image aspect has been specified. If no such ancestor exists, then the default implementation of T'Put_Image is the same as described below for a nonderived record type.

Is this rule supposed to break privacy, or to follow it? In particular, if the parent type is a private type and the aspect for the parent is specified in the private part, or for that matter, the Put_Image attribute is specified in the private part even though the parent type is a visible type, is extension aggregate syntax used? (Yes.)

!recommendation

(See summary.)

!wording

Modify 4.10(16/5):

For a nonnull type extension, the default implementation of T'Put_Image depends on whether there exists a noninterface ancestor of T (other than T itself) for which the Put_Image aspect has been directly specified {[redundant:(visibly or privately)]}. If so, then T'Put_Image will generate an image based on extension aggregate syntax where the ancestor type of the extension aggregate is the nearest ancestor type whose Put_Image aspect has been specified. If no such ancestor exists, then the default implementation of T'Put_Image is the same as described below for a nonderived record type.

{AARM Reason: The default implementation for Put_Image does not respect privacy in general, so extension aggregate syntax is used by default even if the aspect specification for the ancestor is only given in the private part.}

!discussion

In general we know that Put_Image breaks privacy, so this rule should also break privacy for deciding whether or not to use extension aggregate syntax.

To see why, consider an extension of a language-defined container type, which is supposed to have a useful Put_Image aspect which produces something approximating a container aggregate syntax. That Put_Image is not defined visibly; it has to be defined in the private part. When such a type is extended, we certainly don’t want to see all the private components of the container type.

!corrigendum 4.10(16/5)

@drepl

For a nonnull type extension, the default implementation of T'Put_Image depends on whether there exists a noninterface ancestor of T (other than T itself) for which the Put_Image aspect has been directly specified. If so, then T'Put_Image will generate an image based on extension aggregate syntax where the ancestor type of the extension aggregate is the nearest ancestor type whose Put_Image aspect has been specified. If no such ancestor exists, then the default implementation of T'Put_Image is the same as described below for a nonderived record type.

@dby

For a nonnull type extension, the default implementation of T'Put_Image depends on whether there exists a noninterface ancestor of T (other than T itself) for which the Put_Image aspect has been directly specified (visibly or privately). If so, then T'Put_Image will generate an image based on extension aggregate syntax where the ancestor type of the extension aggregate is the nearest ancestor type whose Put_Image aspect has been specified. If no such ancestor exists, then the default implementation of T'Put_Image is the same as described below for a nonderived record type.

!ACATS test

An ACATS C-Test should test that the default Image is as defined when Put_Image is overridden in the private part and the type is later extended.

!appendix

See issue #71 on ARG GitHub issue list.