!standard 13.1(9/5) 17-07-20 AI12-0222-1/02 !standard 13.1(9.1/4) !standard 13.1(9.2/5) !class binding interpretation 17-04-10 !status Amendment 1-2012 17-07-20 !status WG9 Approved 17-10-13 !status ARG Approved 8-0-2 17-06-16 !status work item 17-04-10 !status received 17-01-16 !priority Medium !difficulty Easy !qualifier Omission !subject Representation aspects and private types !summary A representation aspect cannot be specified with an aspect specification on a private type. !question 13.1(9/5) says in part: In addition, a representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1). A representation item does NOT include an aspect_specification. So it appears that: package P is type Priv is private with Size => 16; -- Should be illegal. private type Priv is range 1 .. 1000; end P; is legal, even though the equivalent: package P is type Priv is private; for Priv'Size use 16; -- Illegal. private type Priv is range 1 .. 1000; end P; is clearly illegal by 13.1(9/5). Was this intended? (No.) !recommendation (See Summary.) !wording Replace 13.1(9/5, 9.1/4, and 9.2/5): A representation item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.14). In addition, a representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1). An operational item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.14). An expression or name that freezes an entity shall not occur within an aspect_specification that specifies a representation or operational aspect of that entity. with: A representation item or operational item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.14). An expression or name that freezes an entity shall not occur within an aspect_specification that specifies a representation or operational aspect of that entity. A representation aspect of a subtype or type shall not be specified (whether by a representation item or an aspect_specification) before the type is completely defined (see 3.11.1). Adjust AARM notes as follows: Drop ", see next paragraph" from AARM 13.1(9.a/1); it stays after the first changed paragraph. AARM 13.1(9.c/1) would move after the new 13.1(9.2/5), but is otherwise unchanged. !discussion It's relatively important to fix this: exhibit #1 is that the author managed to ask the same question twice about 10 weeks apart. The wording was carefully crafted so that the AARM notes don't need to move and only need very minor changes. In particular, 13.1(9.c/1) works perfectly after the new 13.1(9.2/5). Additionally, we'd arranged the wording so that the kinds of entities that we're talking about is the same for all sentences of a paragraph. Note that we've included 13.1(9.2/5); it is unchanged but moved so that all of the freezing rules are together. !corrigendum 13.1(9/5) @drepl A representation item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.14). In addition, a representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1). @dby A representation item or operational item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.14). !corrigendum 13.1(9.1/4) @drepl An operational item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.14). @dby An @fa or @fa that freezes an entity shall not occur within an @fa that specifies a representation or operational aspect of that entity. !comment !corrigendum 13.1(9.2/5) -- This paragraph is added by the conflict file; it can't appear here. !comment !comment @drepl !comment An @fa or @fa that freezes an entity shall not occur within !comment an @fa that specifies a representation or operational !comment aspect of that entity. !comment @dby !comment A representation aspect of a subtype or type shall not be specified (whether !comment by a representation item or an @fa) before the type is !comment completely defined (see 3.11.1). !ASIS No ASIS effect. !ACATS test An ACATS B-Test could be created to check this new rule, or the case added to an existing test. !appendix From: Randy Brukardt Sent: Monday, January 16, 2017 9:49 PM 13.1(9/5) says in part: In addition, a representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1). A representation item does NOT include an aspect_specification. So it appears that: package P is type Priv is private with Size => 16; private type Priv is range 1 .. 1000; end P; is legal, even though the equivalent: package P is type Priv is private; for Priv'Size use 16; private type Priv is range 1 .. 1000; end P; is clearly illegal by 13.1(9/5). I suspect that the intent was that we'll allow early specification of representation aspects before the full definition as the resolution/evaluation is delayed to the first freezing point. But I don't think we intended to allow the specification of representation aspects on partial views. There doesn't seem to be any Legality Rule to that effect in 13.1 or 13.1.1. Thus, we need a rule to that effect, probably added to 13.1(9/5): An aspect_specification for a representation aspect shall not appear on an incomplete or partial view. Note that we do allow operational aspects on partial views (that's the main difference between operational and representation aspects). Thoughts? Did I miss something? **************************************************************** From: Tucker Taft Sent: Tuesday, January 17, 2017 5:20 PM > ... Thus, we need a rule to that effect, probably added to 13.1(9/5): > > An aspect_specification for a representation aspect shall not > appear on an incomplete or partial view. Good catch! > Thoughts? Did I miss something? I think you are right. **************************************************************** From: Jeff Cousins Sent: Thursday, January 19, 2017 7:12 AM > ... Thus, we need a rule to that effect, probably added to 13.1(9/5): > > An aspect_specification for a representation aspect shall not > appear on an incomplete or partial view. We seem to be forever re-writing that paragraph, but I think you have a point, and quite an important one. **************************************************************** From: Randy Brukardt Sent: Thursday, March 30, 2017 8:43 PM 13.1(9/5) says (as reworded by AI12-0181-1, but it's had similar wording forever): In addition, a representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1). Since an aspect specification is not a representation item (see the list in 13.1(1/1)), this rule doesn't apply to aspect specifications. But I'd expect that a similar rule applies to aspect specifications: "Aspect specifications for representation aspects of a type or subtype shall not appear on a partial view." You might think that 13.1.1(14/3) "The aspect identified by the aspect_mark shall be an aspect that can be specified for the associated entity (or view of the entity defined by the associated declaration)." would prevent this, but 13.1.1(23-27/3) says (by omission) that type and subtype aspects apply to all views of the entity. So in the case of a private type, the aspects of the full type are the ones that can be specified for the "associated entity". (And then we have to answer the angels-on-a-pin question of whether a private type is a different subtype than the full type that completes it in order to know whether or not subtype aspects are allowed. Let's not go there.) We surely don't want type aspects like Small on a private type (that would clearly break privacy), and I doubt that we want any aspects there, even Size or Alignment, since we don't allow them in the "old" language. So I think the best solution is to add the missing rule, probably near 13.1(9/5) [we've already rearranged this bunch of paragraphs once, changing all of the numbers, we might as well do it a second time, further number changes have no additional cost]. Thus I propose to add after 13.1(9.2/5): Aspect specifications for representation aspects of a type or subtype shall not appear on the declaration of an incomplete or partial view. AARM Reason: We include declarations of subtypes of private types in the prohibition by using "declaration of a partial view" rather than "declaration of a private type". Sadly, this means I can't include this case in the B-Tests I just constructed, but I guess that's life. **************************************************************** From: Erhard Ploederedere Sent: Friday, March 31, 2017 3:24 AM I certainly agree with Randy's intent. But, on the wording, why not simply extend 13.1(9/5) to read > In addition, {an aspect specification for a representation aspect or} > a representation item that directly specif{y}[ies] an aspect of a > subtype or type shall appear after the type is completely defined (see > 3.11.1). My argument is that having two differently phrased rules for the same restriction (it is the same, isn't it?) is not a good idea. **************************************************************** From: Tucker Taft Sent: Friday, March 31, 2017 1:14 PM > ... Thus I propose to add after 13.1(9.2/5): > > Aspect specifications for representation aspects of a type or subtype > shall not appear on the declaration of an incomplete or partial view. > > AARM Reason: We include declarations of subtypes of private types in > the prohibition by using "declaration of a partial view" rather than > "declaration of a private type". Works for me. **************************************************************** From: Tucker Taft Sent: Friday, March 31, 2017 1:16 PM > My argument is that having two differently phrased rules for the same > restriction (it is the same, isn't it?) is not a good idea. Also works for me! Or... In addition, specifying a representation aspect of a subtype or type (whether by a representation item or an aspect specification) shall appear after the type is completely defined (see 3.11.1). **************************************************************** From: Randy Brukardt Sent: Friday, March 31, 2017 3:00 PM > Also works for me! OK, but I don't think it works for the language, though. :-) > Or... > > In addition, specifying a representation aspect of a subtype or type > (whether by a representation item or an aspect specification) shall > appear after the type is completely defined (see 3.11.1). The reason that representation items are handled separately than aspect specifications is that they appear BETWEEN declarations while aspect specifications appear ON declarations. The rule you have here, taken literally, would prevent ever specifying a type-related aspect, because it has to appear ON the completion -- it never appears AFTER the type is completely defined. (Obviously, one would invoke the Dewar rule, but that's silly -- we should get the wording right in the first place.) I had looked at the possibility of sharing the wording, but it doesn't work - for aspect specifications, one has to talk about declarations, not about when the type "is completely defined". Besides, with AI12-0181-1, we separated the rules for representation items and for aspect specifications into different paragraphs because it was getting confusing. In particular, the first sentence of this paragraph (13.1(9/5)) is only about representation items. It would be weird for the second paragraph to then be about both representation items and aspect specifications. So I think we have to have separate wording. I had proposed: Aspect specifications for representation aspects of a type or subtype shall not appear on the declaration of an incomplete or partial view. Perhaps we could turn this around to make it more similar to the existing rule: Aspect specifications for representation aspects of a type or subtype shall only appear on the declaration of a full view of the type. AARM Ramification: A subtype of a full view is also a full view, so subtype-specific aspects can be given on subtypes, but only if the subtype appears after the completion of the type. "Full view" is what it is called, I don't see any way to get "completion" in there without a lot of extra wording as we need to allow subtypes of the full view, and of course types that don't have some sort of partial view don't have completions anyway. Thoughts?? **************************************************************** From: Tucker Taft Sent: Friday, March 31, 2017 3:20 PM > Aspect specifications for representation aspects of a type or subtype > shall only appear on the declaration of a full view of the type. > > AARM Ramification: A subtype of a full view is also a full view, so > subtype-specific aspects can be given on subtypes, but only if the > subtype appears after the completion of the type. I don't think the above really works. "subtype S is T(3);" is not the "declaration of a full view of the type." It is a declaration of a *subtype*, with a constraint. Your prior proposal avoids this problem. The following would also work, I believe: In addition, a representation aspect of a subtype or type shall not be specified (whether by a representation item or an aspect specification) before the type is completely defined (see 3.11.1). **************************************************************** From: Erhard Ploedereder Sent: Saturday, April 1, 2017 12:07 PM > Perhaps we could turn this around to make it more similar to the > existing > rule: > > Aspect specifications for representation aspects of a type or subtype > shall only appear on the declaration of a full view of the type. Yes, turn it around. **************************************************************** From: Erhard Ploedereder Sent: Saturday, April 1, 2017 12:11 PM > In addition, a representation aspect of a subtype or type shall not > be specified (whether by a representation item or an aspect > specification) before the type is completely defined (see 3.11.1). Works for me and I even understand it (until someone points out differently ;-)) ****************************************************************