!standard 3.3(21) 21-05-22 AI12-0407-1/05 !standard 12.3(15) !standard 13.1(8/5) !standard 13.1(8.1/3) !standard 13.1.1(17/5) !standard 13.14(7.2/5) !standard A.5.6(3/5) !standard A.5.6(15/5) !standard A.5.7(3/5) !standard A.5.7(16/5) !standard A.18.2(79.2/5) !standard A.18.3(50.2/5) !standard A.18.5(37.3/5) !standard A.18.6(51.4/5) !standard A.18.8(58.2/5) !standard A.18.9(74.2/5) !standard H.4.1(1/5) !standard H.4.1(3/5) !standard H.4.1(4/5) !standard H.4.1(5/5) !class Amendment 20-11-23 !status Amendment 1-2012 20-11-23 !status WG9 Approved 22-06-22 !status ARG Approved 15-0-0 20-12-09 !status work item 20-11-23 !status received 20-11-23 !priority Low !difficulty Easy !subject Fixups from Draft 26 review - part 1 !summary (1) We use the new named number mechanism in the Big_Number packages, and make some naming improvements. (2) Language-defined aspects cannot be specified on renamings or generic formal parameters unless they explicitly allow those uses. (3) Aspect No_Controlled_Parts is an operational aspect that looks through privacy. (4) Aspect_definitions are frozen at the freezing point of the entity if the aspect is needed for future static semantics and legality checks. The freezing point of an aspect_specification given on a construct that is not a declaration is considered to occur immediately after the specification. (5) A definition of type-related aspects is added. (6) We allow aspects to differ for the replicated actual of a generic formal type. (7) If a name denoting the current instance of a type denotes an object (as opposed to a value) then it denotes a variable view of the object. (8) Stable views of containers do not have Aggregate aspects (and consequently do not support aggregates). !problem (1) AI12-0394-1 added a mechanism to use named numbers with user-defined literals. But we did not add that mechanism to the Big_Reals package. That isn't responsive to the original question. (2) The Nonblocking/Global changes included removing 13.1.1(17/5), with the body portion of the rule being moved to 13.1.1(18/5). But this removes the renaming and generic formal parameter parts of the rule. While we now have some aspects that we allow on generic formal parameters, the majority of aspects are not view-specific. For such aspects, we need matching or replacement rules in order to support them on renaming and generic formal parameters. No such rules exist for most aspects; their definitions assumed that 13.1.1(17/5) eliminated the need. We need some sort of replacement. (3) Legality Rules in Ada generally do not look through private types at the full definition. For aspect No_Controlled_Parts, this would allow hiding controlled components in a private type. That would defeat the purpose of the aspect. (4) The updated rules 13.14(7.2/5) and 13.14(15.2/5) for freezing of aspect_specifications do not cover all possible operational aspects, and potentially could defer freezing of operation aspects until after they are needed to enforce a Legality Rule. We don't want constructs for which there is no freezing rules defined, and we certainly don't want freezing to happen after something is used. (5) There is no definition of "type-related aspect" and "subtype-related aspect" in the RM. There is a To Be Honest note that claims to do that, but it depends on a definition for representation items (and later, operational items). Aspects that do not have a representation item or an operation item are not normatively classified at all. Given that we have included "type-related" in a number of rules in 13.1, this oversight should be corrected. (6) 12.3(15) says that the properties of a generic formal parameter in an instance are exactly the same as those of the actual. We allow adding Pre and Post assertions to generic formal subprograms (which are then added to those of the actual), but there is no allowance for this difference in 12.3(15). (7) The list of variable objects in 3.3 (created by AI12-0392-1 as the inverse of the previous list) does not mention the current instance of a type. That would seem to imply that the following commonly-used idiom is illegal because the 'Access attribute reference is of an access-to-variable type: package Pkg is type T; type T_Ref (Ref : access T) is null record; type T is limited record Self : T_Ref (T'Access); end record; end Pkg; The previous list assumed that all current instances of types and subtypes were variables, but 8.6(17.1/5) says that current instances in aspect specifications represent values (which necessarily are constants). (8) A stable view of a container is intended to eliminate the need for tampering checks by ensuring that no operations that tamper (change the size of the container) are supported. This includes Append and Insert. However, the stable view types include Aggregate aspects that call non-existent Append and Insert routines. That doesn't make sense. !proposal (1) Add renamings of From_String to From_Universal_Image to both the Big_Integer and Big_Real packages. Use From_Universal_Image as the Integer_Literal/Real_Literal aspect. Add an expression function to Big_Real to provide the two parameter version of From_Universal_Image. (2) Replace a version of 13.1.1(17/5), with the words "unless otherwise specified for a specific aspect" preceding it. (3) Clarify that No_Controlled_Parts looks through privacy when enforcing its restrictions. Improve the generic assume-the-worst rules. (4) Revise 13.14(7.2/5) to make it clear that it applies to any aspect that is needed to enforce a Legality Rule, or otherwise affects static semantics. Also revise that paragraph to ensure that it covers aspect_specifications given on constructs that do not declare an entity. (5) Add a definition of type-related aspect and subtype-related aspect after 13.1(8.1/3). (6) Add an exception to explicitly defined differences for a generic formal parameter in an instance. (7) 8.6(17-17.1) defines some current instances as objects, and others as values. The objects should be variable objects, while the values are not objects at all and thus cannot be variable. We word the new bullet to reflect that. (8) Remove the aggregate aspects from the stable view type declarations. !wording Replace the deleted 3.3(21) with: * the current instance of a type other than a protected type@Redundant[, if the current instance is an object and not a value (see 8.6)]; AARM Reason: We exclude current instances of protected types as they are protected units and the next bullet applies. AARM Proof: This list of bullets only applies to views of objects, so current instances that are not objects are not considered here. Modify 12.3(15): In an instance, a generic_formal_parameter_declaration declares a view whose properties are identical to those of the actual, except {when}[as] specified {otherwise (in particular, see 6.1.1, "Preconditions and Postconditions",} [in] 12.4, "Formal Objects"{,} and 12.6, "Formal Subprograms"). Similarly, for a declaration within a generic_formal_parameter_declaration, the corresponding declaration in an instance declares a view whose properties are identical to the corresponding declaration within the declaration of the actual. AARM Reason: In particular, we allow differences for aspects that can be specified on generic formal parameters. For instance, Pre (see 6.1.1) can be specified on generic formal subprograms to be added to the Pre of the actual. Modify 13.1(8/5): A representation item /directly specifies a representation aspect/ of the entity denoted by the local_name, except in the case of a type-related representation item, whose local_name shall denote a first subtype, and which directly specifies an aspect of the subtype's type. A representation item that names a subtype is either subtype-specific (Size, Object_Size, and Alignment clauses) or type-related (all others). [Subtype-specific aspects may differ for different subtypes of the same type.] [Editor's note: This last sentence is moved below.] Delete AARM 13.1(8.a). Add after 13.1(8.1/3): Aspects that can be specified for types and subtypes are also classified into type-related or subtype-specific aspects. Representation aspects that can be specified for types and subtypes are considered type-related unless specified otherwise. In contrast, the classification of operational aspects are given with the definition of the aspect. Type-related aspects have the same value for all subtypes of (a view of) a type@Redundant[, while subtype-specific aspects may differ for different subtypes of the same type]. AARM Discussion: We talk about "type-related aspects", which of course include both type-related representation aspects and type-related operational aspects. Aspects Size, Object_Size, and Alignment are subtype-specific, as that is specified above. All other representation aspects are either type-related or not specifiable for a type or subtype. Unlike representation aspects, there is no default for operational aspects; whether they are type-related or subtype-specific should be part of the definition of the aspect. Replace deleted 13.1.1(17/5) with: Unless otherwise specified for a specific aspect, a language-defined aspect cannot be specified on a renaming_declaration or a generic_formal_parameter_declaration. Modify 13.14(7.2/5): At the freezing point of the entity associated with an aspect_specification, any static expressions within the aspect_specification cause freezing, as do expressions or names in aspect_definitions for representation aspects, or operational aspects that have a corresponding operational attribute. {Similarly, if an aspect_definition for an operational aspect, other than an assertion aspect, could affect the Name Resolution, Static Semantics, or Legality Rules of a subsequent construct, then any expressions or names within the aspect_definition cause freezing at the freezing point of the associated entity.} Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list. {For the purposes of this rule, if there is no declared entity associated with an aspect_specification, the freezing point is considered to occur immediately following the aspect_specification.} Modify A.5.6(3/5): type Big_Integer is private with Integer_Literal => From_[String]{Universal_Image}, Put_Image => Put_Image; Add after A.5.6(15/5): function From_Universal_Image (Arg : String) return Valid_Big_Integer renames From_String; Modify A.5.7(3/5): type Big_Real is private with Integer_Literal => From_[String]{Universal_Image}, Put_Image => Put_Image; Add after A.5.7(16/5): function From_Universal_Image (Arg : String) return Valid_Big_Real renames From_String; function From_Universal_Image (Num, Den : String) return Valid_Big_Real is (Big_Integers.From_Universal_Image (Num) / Big_Integers.From_Universal_Image (Den)); In A.18.2(79.2/5), A.18.3(50.2/5), A.18.5(37.3/5), A.18.6(51.4/5), A.18.8(58.2/5), A.18.9(74.2/5), remove the Aggregate aspect. Modify H.4.1(4/5): If No_Controlled_Parts is True for a type, no component of the type shall have a controlled part nor shall the type itself be controlled. {For the purposes of this rule, a type has a controlled part if its full type has a controlled part; this is applied recursively.} In addition to the places where Legality Rules normally apply (see 12.3), this rule also applies in the private part of an instance of a generic unit. Add an AARM note: AARM Discussion: This check breaks privacy by looking at the full definition of all of the types involved. This is more like a representation aspect than an operational aspect, but representation aspects are not allowed on partial views and we need this aspect to be visible. Modify H.4.1(5/5): When enforcing the above rule within a generic body {G or within the body of a generic unit declared within the declarative region of generic unit G}, a generic formal private type {of G} and a generic formal derived type {of G whose ancestor is a tagged type whose No_Controlled_Parts aspect is False} [of a composite type] are considered to have a controlled part. AARM To Be Honest: If the ancestor of the generic derived type is class-wide, the aspect in question belongs to the specific type associated with the class-wide type. !discussion This AI is a companion to AI12-0404-1. That AI contains wording changes only, where no meaning (semantics) is intended to be changed. This AI contains cases where there is new or changed semantics. (1) (See proposal.) (2) The alternative of checking all aspect definitions and changing those that need definitions (or rules against specifications) would certainly require too much change. Ada 95 had rules preventing the specification of attributes for both renames and generic formal parameters, so the original aspects like Size and Alignment were not designed to support such usages. (3) For a formal derived type, only ancestor types that are tagged types that have No_Controlled_Parts False could cause a problem. Untagged types cannot add components, so it is obvious from the ancestor type whether any controlled types are involved. And of course if No_Controlled_Parts is true for the ancestor, then there are no controlled components by definition. The generic body rule does not use our usual wording, which is messy but takes into account the possibility of nested or child generics. We change it to use that. (4) We want freezing rules to be defined for all kinds of aspects, since no one wants implementation-defined aspects to have to invent their own freezing rules. (5) The definition echoes the definition for representation items and for operational items. We also add an definition of "type-related" - the value is the same for all subtypes of a single view of the type. This has always been assumed but not stated. (6) We chose general wording about properties of generic formal parameters beinging allowed to be different if there is an explicit rule to that effect, rather than a specific fix for specific aspects or just for aspects, in order that we don't have to revisit this paragraph when defining aspects or other characteristics in the future. (7) We do not want to repeat any of 8.6 in 3.3, it's too messy. So we just refer to it to avoid confusion. The list in 3.3 is roughly in the order that the concepts appear in the Standard. So we put "current instance of a type" (from 8.6) before "current instance of a protected unit" (mostly 9.4). We exclude protected types from the new bullet -- the protected unit rule applies to them. (8) Container aggregates are generally built up element-by-element into an empty container. (Only the indexed aggregates work differently.) This is incompatible with the intent of a stable view, which never changes length as long as the stable view exists. As such, the only choice is to remove the Aggregate attributes. !corrigendum 3.3(21/3) @drepl @xbullet or an @fa;> @dby @xbullet !corrigendum 12.3(15) @drepl In an instance, a @fa declares a view whose properties are identical to those of the actual, except as specified in 12.4, “Formal Objects” and 12.6, “Formal Subprograms”. Similarly, for a declaration within a @fa, the corresponding declaration in an instance declares a view whose properties are identical to the corresponding declaration within the declaration of the actual. @dby In an instance, a @fa declares a view whose properties are identical to those of the actual, except when specified otherwise (in particular, see 6.1.1, "Preconditions and Postconditions", 12.4, "Formal Objects", and 12.6, "Formal Subprograms"). Similarly, for a declaration within a @fa, the corresponding declaration in an instance declares a view whose properties are identical to the corresponding declaration within the declaration of the actual. !corrigendum 13.1(8/3) @drepl A representation item @i a @i of the entity denoted by the @fa, except in the case of a type-related representation item, whose @fa shall denote a first subtype, and which directly specifies an aspect of the subtype's type. A representation item that names a subtype is either @i (Size and Alignment clauses) or @i (all others). Subtype-specific aspects may differ for different subtypes of the same type. @dby A representation item @i a @i of the entity denoted by the @fa, except in the case of a type-related representation item, whose @fa shall denote a first subtype, and which directly specifies an aspect of the subtype's type. A representation item that names a subtype is either @i (Size, Object_Size, and Alignment clauses) or @i (all others). !corrigendum 13.1(8.1/3) @dinsa An operational item @i an @i of the entity denoted by the @fa, except in the case of a type-related operational item, whose @fa shall denote a first subtype, and which directly specifies an aspect of the type of the subtype. @dinst Aspects that can be specified for types and subtypes are also classified into type-related or subtype-specific aspects. Representation aspects that can be specified for types and subtypes are considered type-related unless specified otherwise. In contrast, the classification of operational aspects are given with the definition of the aspect. Type-related aspects have the same value for all subtypes of (a view of) a type, while subtype-specific aspects may differ for different subtypes of the same type. !corrigendum 13.1.1(17/3) @drepl There are no language-defined aspects that may be specified on a @fa, a @fa, a @fa, a @fa, a @fa, a @fa, or a @fa other than a @fa. @dby Unless otherwise specified for a specific aspect, a language-defined aspect cannot be specified on a @fa or a @fa. !corrigendum 13.14(7.2/3) @drepl @xbullet, any @fas or @fas within the @fa cause freezing. Any static expressions within an @fa also cause freezing at the end of the immediately enclosing declaration list.> @dby @xbullet, any static expressions within the @fa cause freezing, as do @fas or @fas in @fas for representation aspects, or operational aspects that have a corresponding operational attribute. Similarly, if an @fa for an operational aspect, other than an assertion aspect, could affect the Name Resolution, Static Semantics, or Legality Rules of a subsequent construct, then any @fas or @fas within the @fa cause freezing at the freezing point of the associated entity. Any static expressions within an @fa also cause freezing at the end of the immediately enclosing declaration list. For the purposes of this rule, if there is no declared entity associated with an @fa, the freezing point is considered to occur immediately following the @fa.> !corrigendum A.5.6(0) @dinsc See the conflict file for the changes. !corrigendum A.5.7(0) @dinsc See the conflict file for the changes. !comment The container changes are not shown here. !corrigendum H.7.1(0) @dinsc See the conflict file for the changes. !corrigendum H.4.1(0) @dinsc @s8<@i> For a type, the following type-related, representation aspect may be specified: @xhang<@xterm The type of this aspect is Boolean. If True, the type and any descendants shall not have any controlled parts. If specified, the value of the expression shall be static. If not specified, the value of this aspect is False.> @s8<@i> If No_Controlled_Parts is True for a type, no component of the type shall have a controlled part nor shall the type itself be controlled. For the purposes of this rule, a type has a controlled part if its full type has a controlled part; this is applied recursively. In addition to the places where Legality Rules normally apply (see 12.3), this rule also applies in the private part of an instance of a generic unit. When enforcing the above rule within a generic body @i or within the body of a generic unit declared within the declarative region of generic unit @i, a generic formal private type of @i and a generic formal derived type of @i whose ancestor is a tagged type whose No_Controlled_Parts aspect is False are considered to have a controlled part. !ASIS No ASIS effect. !ACATS test ACATS B- and C-Tests are needed to check that the new capabilities are supported. !appendix From a private conversation: Arnaud Charlet: We forgot to use AI12-0394-1 in the Big_Real package. We need to add a two parameter From_String to Big_Real. Steve Baird: It's bizarre to call a routine with TWO String parameters "From_String". Tucker Taft: The name has to be the same as the one parameter version. Randy Brukardt: "From_String" seems strange to me as well. Perhaps we should call it From_Literal, with a renaming from From_String for the one parameter version and an expression function for the two parameter version. Steve Baird: From_Literal doesn't help, only the one parameter version has anything to do with literals and that's loose (the compiler has already converted them to a string before these routines get called). How about calling them From_Text? Tucker Taft: That's hardly different than From_String in my mind. How about From_Universal_Integer and From_Universal_Real? The length of the names of these functions doesn't matter much, since they are mainly compiler- generated calls. Perhaps From_Universal would be better, since that would be the same for both packages. Steve Baird: There's no universals anywhere to be seen for these functions, so From_Universal doesn't do it for me. How about From_Universal_Image? All: Yea, verily! **************************************************************** From the AARM review of Jeff Cousins (September 2020). 13.1.1 (38.m/5) Says formal parameters removed from the list of entities without language-defined aspects, but they look to still be there in 13.1.1 (4.c/5) (though the mention in (17/5) has gone – indeed the whole of (17/5) has gone). **************************************************************** From: Randy Brukardt Sent: Tuesday, November 3, 2020 8:51 PM The list in 13.1.1 (4.c/5) was previously fixed (a number of mistakes were found, that being one), but since draft 26 came out. The remaining operative parts of 13.1.1(17/5) were moved to 13.1.1.(18/5). I'm a bit worried that the removal of the 13.1.1(17/5) formal parameter part might start allowing aspect specifications for other existing language-defined aspects. With that rule gone, we have to look at the entire list of aspects (and attributes) to ensure that none of them could be used on a generic formal. The whole reason we had this rule was because that was too hard to do. So I wonder if we would be better served replacing 13.1.1(17/5) as a default for formals and renamings: Unless otherwise specified for a specific aspect, a language-defined aspect cannot be specified on a @fa or a @fa. (We don't want Size or Pre or Pack or many others specified on renamings or on formals, as we don't have any sort of matching rules.) **************************************************************** From: Tucker Taft Sent: Wednesday, November 4, 2020 6:14 AM I agree with all of your dispensations for Jeff's comments. ... **************************************************************** Summary of private mail, October 21-22, 2020. Steve Baird: uppose user X asserts that the following example is illegal because the element type of T2 is controlled: with Ada.Finalization; package Pkg1 is type T1 is private; private type T1 is new Ada.Finalization.Controlled with null record; end Pkg1; with Pkg1; package Pkg2 is type T2 is array (Boolean) of Pkg1.T1 with No_Controlled_Parts; end; But then user Y responds "No, T2's element type isn't controlled - as seen from the point where the No_Controlled_Parts rule is enforced, the element type is an untagged private type. So the example is legal." . It seems to me that X's interpretation is pretty clearly what was intended, but Y's interpretation is what you get from a strict reading of the existing RM wording. Is there a problem here? Tucker Taft: Yes. How do your recommend we fix it? Actually, since this is a restriction, we generally allow these things to see through privacy. Wouldn't that simplify things substantially? Randy Brukardt: As Steve said, it's not a restriction, it's an operational attribute. But I'm not sure why it's operational, it has more in common with representation attributes, I'd think, and those generally ignore privacy as well. Tucker Taft: If by making it a representation aspect we eliminate most of this complexity, I am all in favor. It is effectively a restriction -- it doesn't introduce or override any existing implicit operation on the type -- it merely makes certain otherwise legal programs illegal. There is nothing particularly "operational" about it. Steve Baird: == start digression #1 == I see another H.4.1 problem. We've got When enforcing the above rule within a generic body, a generic formal private type and a generic formal derived type of a composite type are considered to have a controlled part. Seems like "generic formal derived type" should be "generic formal derived TAGGED type". But because this aspect is nonoverridable, we also want to allow a formal derived tagged type if the No_Controlled_Parts aspect of the ancestor type is True. So that change (by itself) isn't quite right. == end digression #1 == Randy Brukardt: Can't an untagged composite type have controlled components? That has to be covered for generic derived types. You could exclude elementary ancestors, I guess. Steve Baird: In the untagged case, derivation cannot add new controlled components that were not already present in the ancestor type. If a formal untagged derived type does not appear to have any controlled parts, then the actual parameter for a particular instance isn't going to provide any unpleasant surprises. Steve Baird: == start digression #2 == We've got (in H.4.1) When enforcing the above rule within a generic body, a generic formal private type and a generic formal derived type of a composite type are considered to have a controlled part. Should that rule be limited to generic formal types of the generic whose body we are within (as opposed to formals of other generics)? == end digression #2 == Randy Brukardt: You can be inside of multiple generic bodies at the same time, because of nested generic units or even child generic units. All of our wording uses plural for that reason. Perhaps you are complaining that we didn't use *exactly* the magic words we used elsewhere. Specifically: "Additionally, if occurs within the body of a generic unit G or within the body of a generic unit declared within the declarative region of generic unit G, then ..." Here's my try at the fixes needed: (1) Change this to a representation aspect. Delete H.4.1(3/5) ["nonoverridable" is only defined for operational aspects. But this is a Boolean aspect subject to blanket rules like Atomic and Pack and many other aspects that prevent it from being specified False for derived types that have an ancestor that specify it True. Representation aspects have detailed inheritance rules. Do we need anything else??] (2) Modify H.4.1(4/5): If No_Controlled_Parts is True for a type, no component of the type shall have a controlled part nor shall the type itself be controlled. {For the purposes of this rule, a type has a controlled part if its full type has a controlled part; this is applied recursively.} In addition to the places where Legality Rules normally apply (see 12.3), this rule also applies in the private part of an instance of a generic unit. Add an AARM note: AARM Discussion: Like most representation aspects, this check breaks privacy by looking at the full definition of all of the types involved. (3) Modify H.4.1(5/5): When enforcing the above rule within a generic body {G or within the body of a generic unit declared within the declarative region of generic unit G}, a generic formal private type {of G} and a generic formal derived type {of G whose ancestor is a tagged type whose No_Controlled_Parts aspect is False} [of a composite type] are considered to have a controlled part. AARM To Be Honest: If the ancestor of the generic derived type is class-wide, the aspect in question belongs to the specific type associated with the class-wide type. ------------ Addendum, November 23, 2020 The reason that we had No_Controlled_Parts as operational was so that it could be visibly specified on a private type. The reason that we had No_Controlled_Parts as nonoverridable was to deal with the conflicting progenitor problem. (We don't care about breaking privacy for the aspect, since we're doing that in any case, but it would be too painful to define a separate set of rules just for this aspect.) As such, I've removed those changes from the proposal. **************************************************************** Part of a private review of AI12-0396-1. From: Randy Brukardt, November 25. The current wording for the freezing rules in AI12-0396-1 is: 13.14(7.2/5): At the freezing point of the entity associated with an aspect_specification, any static expressions within the aspect_specification cause freezing, as do expressions or names in aspect_definitions for representation aspects, or operational aspects that have a corresponding operational attribute. Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list. 13.14(15.2/5): * At the place where a construct causes freezing, if the construct includes a check associated with some assertion aspect [Redundant: (independent of whether the check is enabled)], or depends on the definition of some operational aspect as part of its Dynamic Semantics, any names or expressions in the aspect_definition for the aspect cause freezing. These rules collectively determine when an aspect_specification (and the included aspect_definitions) are frozen. But for operational aspects, we seem to be missing some cases. Aside: I don't think any cases are missing for language-defined aspects. But it seems to me that we don't want implementation-defined freezing rules (and I doubt any implementers want to be inventing such things). So I don't think we want holes here. There are two cases that aren't covered. First of all, when we have constructs that are not declarations (like loops) that allow aspect_specifications, the first rule doesn't apply at all. Thus, the only aspects that have a rule in loop contexts are those that are covered by the second rule [assertion aspects and operational aspects with Dynamic Semantics effects]. Even if we assume that there aren't any representation aspects for loops (not sure if that makes sense or not), that seems to leave a truck-sized hole for any (operational) aspects that only have Static Semantic/Legality Effects -- and even if those have Dynamic Semantics as well, they very well might be frozen too late for Legality enforcement. Second, the aspect_definition for any operational aspects that don't require static expressions and don't have Dynamic Semantics nor associated operational items are never frozen anywhere. I note that a lot of types can't be static, including System.Address and any composite type. Nor can objects or subprograms be static. So it is relatively easy to imagine aspects that would not have any freezing rules at all. (Imagine an aspect that required a compile-time address or a library-level object.) As noted previously, I don't think this is a good idea to leave these cases undefined. It's fairly clear that there should be a "else" here! The second problem is fairly easy to fix. We just need to ensure that the rules in the two paragraphs are mirrors of each other. I'd suggest doing that by changing the first paragraph to be closer to the second: At the freezing point of the entity associated with an aspect_specification, any static expressions within the aspect_specification cause freezing, as do expressions or names in aspect_definitions for representation aspects, or operational aspects that have a corresponding operational attribute {or are neither assertion aspect nor have a Dynamic Semantics effect}. Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list. or maybe more positively (since it isn't a problem to freeze something twice): At the freezing point of the entity associated with an aspect_specification, any static expressions within the aspect_specification cause freezing, as do expressions or names in aspect_definitions for representation aspects, or operational aspects that have a corresponding operational attribute {or have an effect on the legality of some other construct and are not an assertion aspect}. Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list. The first problem appears to need an additional rule (put it after 13.14(8.2/1)): For an aspect_specification that appears in a construct that is not the declaration of an entity, any static expressions within the aspect_specification cause freezing, as do expressions or names in aspect_definitions for aspects that have an effect on the legality of some construct (including the construct with the aspect_specification) and are not an assertion aspect. AARM To Be Honest: This rule applies to aspect_specifications in loop_statements. A loop may contain contains a declaration of a loop parameter, but that is a separate syntactic construct from the one that contains the aspect_specification. A similar analysis applies to other kinds of iterator. Thoughts?? From: Tucker Taft, November 26, 2020. ... > At the freezing point of the entity associated with an > aspect_specification, any static expressions within the > aspect_specification cause freezing, as do expressions or names in > aspect_definitions for representation aspects, or operational aspects > that have a corresponding operational attribute {or have an effect on > the legality of some other construct and are not an assertion > aspect}. Any static expressions within an aspect_specification also > cause freezing at the end of the immediately enclosing declaration > list. That first sentence seems to be getting a bit complex. Perhaps we can break it up a bit: At the freezing point of the entity associated with an aspect_specification, any static expressions within the aspect_specification cause freezing, as do expressions or names in aspect_definitions for representation aspects, or operational aspects that have a corresponding operational attribute. {Similarly, if an aspect_definition for an operational attribute, other than an assertion aspect, could affect the Name Resolution, Static Semantics, or Legality Rules of a subsequent construct, then any expressions or names within the aspect_definition cause freezing at the freezing point of the associated entity.} Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list. > The first problem appears to need an additional rule (put it after > 13.14(8.2/1)): > > For an aspect_specification that appears in a construct that is not > the declaration of an entity, any static expressions within the > aspect_specification cause freezing, as do expressions or names in > aspect_definitions for aspects that have an effect on the legality of > some construct (including the construct with the > aspect_specification) and are not an assertion aspect. > > AARM To Be Honest: This rule applies to aspect_specifications in > loop_statements. A loop may contain contains a declaration of a loop > parameter, but that is a separate syntactic construct from the one > that contains the aspect_specification. A similar analysis applies to > other kinds of iterator. This seems a bit excessive for this one special case. How about we just add this to the end of 13.14(7.2): For the purposes of this rule, if there is no declared entity associated with an aspect_specification, the freezing point is considered to occur immediately following the aspect_specification. **************************************************************** Part of a private review of AI12-0396-1. From: Randy Brukardt, November 25. 13.1(8/3) is now: A representation item directly specifies a representation aspect of the entity denoted by the local_name, except in the case of a type-related representation item, whose local_name shall denote a first subtype, and which directly specifies an aspect of the subtype's type. A representation item that names a subtype is either subtype-specific (Size, Object_Size, and Alignment clauses) or type-related (all others). [Redundant: Subtype-specific aspects may differ for different subtypes of the same type.] This is mostly unchanged from Ada 2012. But we have a To Be Honest note following it: To be honest: Type-related and subtype-specific are defined likewise for the corresponding aspects of representation. This means that we have no normative definition for "type-related representation aspect", and in particular, we have no definition at all (even in the AARM) for an aspect that doesn't have any representation items. To "fix" this latter problem, I added some text to the note above: To be honest: Type-related and subtype-specific are defined likewise for the corresponding aspects of representation. {The terms are also defined for aspects of representation that do not have corresponding representation items; these also are type-related unless explicitly specified otherwise.} I also added a similar note after the following paragraph about operational aspects. To Be Honest: Type-related and subtype-related are defined likewise for the corresponding operational aspects, and are defined as well for operational aspects that apply to types but do not have corresponding operational items. Unlike representation aspects, we explicitly define operational aspects to be type-related (that is the default for representation aspects). However, I think this is very much a bridge too far. I think it would be a lot better to add an appropriate overall definition after 13.1(8.1/3). Perhaps something like: Aspects that can be specified for types and subtypes are also classified into type-related or subtype-specific aspects. Representation aspects that can be specified for types and subtypes are considered type-related unless specified otherwise. In contrast, the classification of operational aspects are given with the definition of the aspect. AARM Discussion: We talk about "type-related aspects", which of course include both type-related representation aspects and type-related operational aspects. Aspects Size, Object_Size, and Alignment are subtype-specific, as that is specified above. All other representation aspects are either type-related or not specifiable for a type or subtype. Unlike representation aspects, there is no default for operational aspects; whether they are type-related or subtype-specific should be part of the definition of the aspect. If we added this, we could get rid of both of those "To Be Honest" notes. (Perhaps the AARM note could be tightened up - it's not my best work!) From: Tucker Taft, November 26 The above seems like a good change. **************************************************************** From WG 9 review issue #38 12.3(5.n/5) "We allow differences{,} in particular{,} for aspects that can be specified on generic formal parameters." [Editor's reply: It makes more sense to move the "in particular" to the front, giving: In particular, we allow differences for aspects that can be specified on generic formal parameters. This was treated as an Editorial Review change.] ****************************************************************