Version 1.7 of ai12s/ai12-0407-1.txt

Unformatted version of ai12s/ai12-0407-1.txt version 1.7
Other versions for file ai12s/ai12-0407-1.txt

!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)

Replace the paragraph:

the object denoted by a function_call or an aggregate;

by:

the current instance of a type other than a protected type, if the current instance is an object and not a value (see 8.6);

!corrigendum 12.3(15)

Replace the paragraph:

In an instance, a generic_formal_parameter_declaration 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 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.

by:

In an instance, a generic_formal_parameter_declaration 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 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.

!corrigendum 13.1(8/3)

Replace the paragraph:

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 and Alignment clauses) or type-related (all others). Subtype-specific aspects may differ for different subtypes of the same type.

by:

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).

!corrigendum 13.1(8.1/3)

Insert after the paragraph:

An operational item directly specifies an operational aspect of the entity denoted by the local_name, except in the case of a type-related operational item, whose local_name shall denote a first subtype, and which directly specifies an aspect of the type of the subtype.

the new paragraph:

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)

Replace the paragraph:

There are no language-defined aspects that may be specified on a renaming_declaration, a generic_formal_parameter_declaration, a subunit, a package_body, a task_body, a protected_body, or a body_stub other than a subprogram_body_stub.

by:

Unless otherwise specified for a specific aspect, a language-defined aspect cannot be specified on a renaming_declaration or a generic_formal_parameter_declaration.

!corrigendum 13.14(7.2/3)

Replace the paragraph:

At the freezing point of the entity associated with an aspect_specification, any expressions or names within the aspect_specification cause freezing. Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list.

by:

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.

!corrigendum A.5.6(0)

Insert new clause:

See the conflict file for the changes.

!corrigendum A.5.7(0)

Insert new clause:

See the conflict file for the changes.

!comment The container changes are not shown here.

!corrigendum H.7.1(0)

Insert new clause:

See the conflict file for the changes.

!corrigendum H.4.1(0)

Insert new clause:

Static Semantics

For a type, the following type-related, representation aspect may be specified:

No_Controlled_Parts: 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.

Legality Rules

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 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 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<renaming_declaration> or a 
  @fa<generic_formal_parameter_declaration>.

(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 <something> 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.]
****************************************************************

Questions? Ask the ACAA Technical Agent