Ada-Rapporteur-Group / User-Community-Input

Ada User Community Input Working Group - Github Mirror Prototype
26 stars 1 forks source link

Put_Image use of extension aggregate syntax #71

Closed sttaft closed 7 months ago

sttaft commented 7 months ago

Ada RM 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?

As an example, 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. What happens when you extend such a type? I would think you don't suddenly want to see all the private components of the container type.

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

In any case, we should clarify this rule, and its interaction with privacy.

ARG-Editor commented 7 months ago

I think it only makes sense for it to break privacy. Put_Image is a primarily a run-time thing, and those ignore privacy. But I agree that this isn't clear, so I suppose we need an AI. Gonna write one in time for the next meeting? (That is, tomorrow. This is not a real question. ;-)

As an aside, I don't think the Bairdian "(other than T itself)" is needed here. If Put_Image is specified for T, no one cares what the default implementation of Put_Image is, because it has been overridden and would never be used. It's insufficiently broken to change, though.

sttaft commented 7 months ago

I would suggest a slight modification, perhaps as follows:

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. {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.}

ARG-Editor commented 7 months ago

AI22-0088-1 has been created for this issue.

ARG-Editor commented 7 months ago

AI22-0088-1 was approved at ARG meeting #63B, so I've closed this issue.