CVS difference for ai05s/ai05-0183-1.txt

--- ai05s/ai05-0183-1.txt 2011/02/08 08:21:06 1.17+++ ai05s/ai05-0183-1.txt 2011/02/15 04:43:41 1.18@@ -1,4 +1,4 @@-!standard 3.2.1(3) 10-11-18 AI05-0183-1/07+!standard 3.2.1(3) 11-02-14 AI05-0183-1/08
!standard 3.2.2(2)
!standard 3.3.1(2/2)
!standard 3.8(6)
@@ -9,6 +9,13 @@
!standard 7.1(3)
!standard 7.3(2)
!standard 7.3(3)
+!standard 8.2(10.1/2)+!standard 8.3(23.1/2)+!standard 8.5.1(2/2)+!standard 8.5.2(2)+!standard 8.5.3(2)+!standard 8.5.4(2/2)+!standard 8.5.5(2)
!standard 9.1(2/2)
!standard 9.1(3/2)
!standard 9.4(2/2)
@@ -80,6 +87,7 @@
* package_declaration;
* private_type_declaration;
* private_extension_declaration;
+ * renaming_declaration;
* task_type_declaration;
* single_task_declaration;
* protected_type_declaration;
@@ -90,16 +98,14 @@
* generic_instantiation;
* generic_formal_parameter_declaration.
-Aspect specification are not permitted on renaming declarations, as-that would seem to break the underlying model of renaming (that properties are-the same as the renamed entity).+At most one occurrence of each aspect is allowed within a single+aspect_specification. The named aspect must be an aspect that can be specified+for the given kind of entity.-At most one occurrence of each aspect is allowed within a single aspect_specification.-The named aspect must be an aspect that can be specified for the given kind of entity.-
The names in the expressions of an aspect_specification
are resolved *not* at the point of the associated declaration, but rather at the
-freezing point of the associated entity. If the aspect_specification occurs+end of the immediately enclosing declaration list, or the first freezing+point, whichever comes first. If the aspect_specification occurs
within a visible part, declarations occuring after the freezing point or
within the corresponding private part are not considered.
@@ -186,6 +192,54 @@
[AND interface_list] WITH PRIVATE
[aspect_specification];
+Modify 8.2(10.1/2):++ The scope of an attribute_definition_clause is identical to the+ scope of a declaration that would occur at the point of the+ attribute_definition_clause. {The scope of an aspect_specification+ is identical to the scope of the associated declaration.}++Modify 8.3(23.1/2):++ An attribute_definition_clause {or an aspect_specification} is+ visible everywhere within its scope.++Replace 8.5.1(2/2) by:++ object_renaming_declaration ::=+ defining_identifier : [null_exclusion] subtype_mark renames object_name+ [aspect_specification];+ | defining_identifier : access_definition renames object_name+ [aspect_specification];++Replace 8.5.2(2) by:++ exception_renaming_declaration ::= defining_identifier : exception renames exception_name+ [aspect_specification];++Replace 8.5.3(2) by:++ package_renaming_declaration ::= package defining_program_unit_name renames package_name+ [aspect_specification];++Replace 8.5.4(2/2) by:++ subprogram_renaming_declaration ::=+ [overriding_indicator]+ subprogram_specification renames callable_entity_name+ [aspect_specification];++Replace 8.5.5(2) by:++ generic_renaming_declaration ::=+ generic package defining_program_unit_name renames generic_package_name+ [aspect_specification];+ | generic procedure defining_program_unit_name renames generic_procedure_name+ [aspect_specification];+ | generic function defining_program_unit_name renames generic_function_name+ [aspect_specification];++
Replace 9.1(2/2) by:
task_type_declaration ::=
@@ -331,7 +385,7 @@
aspect_mark ::= aspect_identifier['Class]
- aspect_definition ::= name | expression+ aspect_definition ::= name | expression | identifier
AARM NOTE: The aspect_specification is an optional element
in most kinds of declarations. Here is a list of all kinds of
@@ -357,9 +411,8 @@
abstract_subprogram_declaration*
null_procedure_declaration*
package_declaration*
- renaming_declaration -- NO- -- Allowing a renaming to change operational or representational- -- aspects would seem to break the underlying model of renaming.+ renaming_declaration* -- There are no+ -- language-defined aspects specifiable on renames.
exception_declaration*
generic_declaration*
generic_instantiation*
@@ -401,12 +454,15 @@
* an aspect that denotes some other kind of entity, the aspect_definition
shall be a name, and the name shall resolve to denote an entity of
- the appropriate kind.+ the appropriate kind;+ * an aspect that is given by an identifier specific to the aspect, the+ aspect_definition shall be an identifier, and the identifier shall+ be one of the identifiers specific to the identified aspect.+
The usage names in an aspect_definition [Redundant: are not resolved at the
point of the associated declaration, but rather] are resolved at the
- end of the immediately enclosing declaration list, or at the first- freezing point of the associated entity, whichever comes first.+ end of the immediately enclosing declaration list.
If the associated declaration is for a subprogram or entry, the names
of the formal parameters are directly visible within the
@@ -422,32 +478,57 @@
Legality Rules
- If the freezing point of the associated entity comes before the end of+ If the first freezing point of the associated entity comes before the end of
the immediately enclosing declaration list, then each usage name in the
- aspect_definition shall resolve to the same declaration at both places.+ aspect_definition shall resolve to the same entity at the first freezing point+ as it does at the end of the immediately enclosing declaration list.
At most one occurrence of each aspect_mark is allowed within a single
aspect_specification. The aspect identified by the aspect_mark
- shall be an aspect that can be specified for the associated entity.+ shall be an aspect that can be specified for the associated entity+ (or view of the entity defined by the associated declaration).
The aspect_definition associated with a given aspect_mark may be omitted only
when the aspect_mark identifies an aspect of a boolean type, in which
case it is equivalent to the aspect_definition being specified as True.
If the aspect_mark includes 'Class, then the associated entity shall be
- a tagged type or the primitive subprogram of a tagged type.+ a tagged type or a primitive subprogram of a tagged type.
Static Semantics
Depending on which aspect is identified by the aspect_mark, an
- aspect_definition specifies a name that denotes a subprogram, object,- or other kind of entity, or an expression, which is either evaluated- to produce a single value, or which (as in a precondition) is to be- evaluated at particular points during later execution. The identified- aspect of the associated entity is as specified by the- aspect_definition (or by the default of True when boolean). If the- aspect_mark includes 'Class, then:+ aspect_definition specifies:++ * a name that denotes a subprogram, object, or other kind of entity;++ * an expression, which is either evaluated to produce a single+ value, or which (as in a precondition) is to be evaluated at+ particular points during later execution; or+ * an identifier specific to the aspect.++ The identified aspect of the associated entity, or in some cases, the+ view of the entity defined by the declaration, is as specified by the+ aspect_definition (or by the default of True when boolean). Whether an+ aspect_specification applies to an entity or only to the particular+ view of the entity defined by the declaration is determined by the+ aspect_mark and the kind of entity. The following aspects are view specific:++ * An aspect specified on an object_declaration;++ * An aspect specified on a subprogram_declaration;++ * The Address aspect;++ * An aspect specified on a renaming_declaration.++ Other aspect_specifications are associated with the entity, and apply+ to all views of the entity, unless otherwise specified in this+ International Standard.++ If the aspect_mark includes 'Class, then:+
* if the associated entity is a tagged type, the specification
applies to all descendants of the type;
@@ -458,11 +539,20 @@
All specifiable operational and representation attributes may be
specified with an aspect_specification instead of an
attribute_definition_clause (see 13.3). The attribute_designator is
- used for the aspect_mark. In addition, other operational and+ used for the aspect_mark. In addition, certain other operational and
representation aspects not associated with specifiable attributes may
be specified, as specified elsewhere in this International Standard.
In the case of aspects specifiable with pragmas, the pragma identifier
- is used for the aspect_mark.+ is used for the aspect_mark, unless otherwise specified in this International+ Standard.++ If an aspect of a derived type is inherited from an ancestor type and+ has the boolean value True, the inherited value shall not be+ overridden to have the value False for the derived type, unless+ otherwise specified in this International Standard.++ There are no language-defined aspects that may be specified on a+ renaming_declaration nor on a formal_type_declaration.
Alternative legality and semantics rules may apply for particular
aspects, as specified elsewhere in this International Standard.
@@ -471,7 +561,7 @@
At the freezing point of the associated entity, the aspect_specification is
elaborated. The elaboration of the aspect_specification includes the
- evaluation of the name or expression, unless the aspect itself is an+ evaluation of the name or expression, if any, unless the aspect itself is an
expression. If the corresponding aspect represents an expression (as in a
precondition), the elaboration has no effect; the expression is evaluated
later at points within the execution as specified elsewhere in this
@@ -541,15 +631,15 @@
would be names such as "Inherited_Pre", but Pre'Class meaning it applies
to T'Class seems more natural.
-We defer resolving the names in the aspect_definition to the first-freezing point or end of the declaration list because in many cases the-entities referenced in the aspect_definition will necessarily, or more-conveniently, be declared after the entity with the aspect-specification. For example, for a type, any aspect that refers to an-operation of the type will be a forward reference. For a subprogram, an-aspect that refers to another subprogram will often be a forward-reference, as ordering the subprograms based on the aspect_definitions-would be painful and sometimes impossible.+We defer resolving the names in the aspect_definition to end of the+enclosing declaration list because in many cases the entities referenced+in the aspect_definition will necessarily, or more conveniently, be+declared after the entity with the aspect specification. For example,+for a type, any aspect that refers to an operation of the type will be a+forward reference. For a subprogram, an aspect that refers to another+subprogram will often be a forward reference, as ordering the+subprograms based on the aspect_definitions would be painful and+sometimes impossible.
If the freezing point comes before the end of the enclosing declaration
list, we require the usage names in the aspect_definition to resolve to
@@ -720,6 +810,84 @@
[>@b<@ft<and>>@fa< interface_list] >@b<@ft<with private>>@fa<
[aspect_specification];>>
+!corrigendum 8.2(10.1/2)++@drepl+The scope of an @fa<attribute_definition_clause> is identical to the scope of a+declaration that would occur at the point of the+@fa<attribute_definition_clause>.+@dby+The scope of an @fa<attribute_definition_clause> is identical to the scope of a+declaration that would occur at the point of the+@fa<attribute_definition_clause>. The scope of an @fa<aspect_specification>+is identical to the scope of the associated declaration.++!corrigendum 8.3(23.1/2)++@drepl+An @fa<attribute_definition_clause> is @i<visible> everywhere within its scope.+@dby+An @fa<attribute_definition_clause> or an @fa<aspect_specification> is+@i<visible> everywhere within its scope.++!corrigedum 8.5.1(2/2)++@drepl+@xcode<@fa<object_renaming_declaration ::=+ defining_identifier : [null_exclusion] subtype_mark >@ft<@b<renames> @i<object_>>@fa<name;+ | defining_identifier : access_definition >@ft<@b<renames> @i<object_>>@fa<name;>>+@dby+@xcode<@fa<object_renaming_declaration ::=+ defining_identifier : [null_exclusion] subtype_mark >@ft<@b<renames> @i<object_>>@fa<name+ [aspect_specification];+ | defining_identifier : access_definition >@ft<@b<renames> @i<object_>>@fa<name+ [aspect_specification];>>++!corrigendum 8.5.2(2)++@drepl+@xcode<@fa<exception_renaming_declaration ::= defining_identifier : >@ft<@b<exception renames> @i<exception_>>@fa<name;>>+@dby+@xcode<@fa<exception_renaming_declaration ::= defining_identifier : >@ft<@b<exception renames> @i<exception_>>@fa<name+ [aspect_specification];>>++!corrigendum 8.5.2(3)++@drepl+@xcode<@fa<package_renaming_declaration ::= >@ft<@b<package>>@fa< defining_program_unit_name >@ft<@b<renames>>@fa< package_>>@fa<name;>>+@dby+@xcode<@fa<package_renaming_declaration ::= >@ft<@b<package>>@fa< defining_program_unit_name >@ft<@b<renames>>@fa< package_>>@fa<name+ [aspect_specification];>>++!corrigendum 8.5.4(2/2)++@drepl+@xcode<@fa<subprogram_renaming_declaration ::=+ [overriding_indicator]+ subprogram_specification >@ft<@b<renames> @i<callable_entity_>>@fa<name;>>+@dby+@xcode<@fa<subprogram_renaming_declaration ::=+ [overriding_indicator]+ subprogram_specification >@ft<@b<renames> @i<callable_entity_>>@fa<name;+ [aspect_specification];>>++!corrigendum 8.5.5(2)++@drepl+@xcode<@fa<generic_renaming_declaration ::=+ >@ft<@b<generic package>>@fa< defining_program_unit_name >@ft<@b<renames> @i<generic_package_>>@fa<name;+ | >@ft<@b<generic procedure>>@fa< defining_program_unit_name >@ft<@b<renames> @i<generic_procedure_>>@fa<name;+ | >@ft<@b<generic function>>@fa< defining_program_unit_name >@ft<@b<renames> @i<generic_function_>>@fa<name;>>+@dby+@xcode<@fa<generic_renaming_declaration ::=+ >@ft<@b<generic package>>@fa< defining_program_unit_name >@ft<@b<renames> @i<generic_package_>>@fa<name+ [aspect_specification];+ | >@ft<@b<generic procedure>>@fa< defining_program_unit_name >@ft<@b<renames> @i<generic_procedure_>>@fa<name+ [aspect_specification];+ | >@ft<@b<generic function>>@fa< defining_program_unit_name >@ft<@b<renames> @i<generic_function_>>@fa<name+ [aspect_specification];>>++
!corrigendum 9.1(2/2)
@drepl
@@ -953,24 +1121,27 @@
@xbullet<an aspect that denotes an object, the @fa<aspect_definition> shall be a
@fa<name>. The expected type for the @fa<name> is the type of the identified
-aspect of the associated entity.>+aspect of the associated entity;>
@xbullet<an aspect that is a value or an expression, the @fa<aspect_definition>
shall be an @fa<expression>. The expected type for the @fa<expression>
-is the type of the identified aspect of the associated entity.>+is the type of the identified aspect of the associated entity;>
@xbullet<an aspect that denotes a subprogram, the @fa<aspect_definition> shall
be a @fa<name>; the expected profile for the @fa<name> is the profile required
-for the aspect of the associated entity.>+for the aspect of the associated entity;>
@xbullet<an aspect that denotes some other kind of entity, the @fa<aspect_definition>
shall be a @fa<name>, and the @fa<name> shall resolve to denote an entity of
-the appropriate kind.>+the appropriate kind;>++@xbullet<an aspect that is given by an identifier specific to the aspect, the+@fa<aspect_definition> shall be an @fa<identifier>, and the @fa<identifier>+shall be one of the identifiers specific to the identified aspect.>
The usage names in an @fa<aspect_definition> are not resolved at the
point of the associated declaration, but rather are resolved at the
-end of the immediately enclosing declaration list, or at the first-freezing point of the associated entity, whichever comes first.+end of the immediately enclosing declaration list.
If the associated declaration is for a subprogram or entry, the names of the
formal parameters are visible within the @fa<aspect_definition>, as are certain
@@ -982,6 +1153,28 @@
@fa<aspect_definition> the name of the new subtype denotes the current instance
of the (sub)type.
+@i<@s8<Legality Rules>>++If the first freezing point of the associated entity comes before the end of+the immediately enclosing declaration list, then each usage name in the+@fa<aspect_definition> shall resolve to the same entity at the first freezing+point as it does at the end of the immediately enclosing declaration list.++At most one occurrence of each @fa<aspect_mark> is allowed within a single+@fa<aspect_specification>. The aspect identified by the @fa<aspect_mark>+shall be an aspect that can be specified for the associated entity+(or view of the entity defined by the associated declaration).++The @fa<aspect_definition> associated with a given @fa<aspect_mark> may+be omitted only when the @fa<aspect_mark> identifies an aspect of a boolean+type, in which case it is equivalent to the @fa<aspect_definition> being+specified as True.++If the @fa<aspect_mark> includes 'Class, then the associated entity shall be+a tagged type or a primitive subprogram of a tagged type.++@i<@s8<Static Semantics>>+
@i<@b<Rest of this text TBD>>
!example
@@ -4482,6 +4675,64 @@
I hope this clarifies my position here. Perhaps I put my initial fears too
strongly, but I cannot abide with leaving this all undefined, or assuming that
the answers determined using an incorrect model of aspects are correct.
++****************************************************************++From: Tucker Taft+Sent: Sunday, February 13, 2011 4:35 PM++Here is a relatively minor update to AI-183 on aspect specifications. We now+allow "identifiers specific to an aspect" in an aspect specification (how's that+for a mouthful?), with the intent of allowing being able to specify a Convention+with an aspect specification. We also allow aspect specifications on renaming+declarations, but indicate there are no language-defined aspects that can be+specified on a renaming.++We also specify that if a boolean aspect is inherited by a derived type as True,+it can't be overridden with a specification of False.++[This is version /08 of the AI. - Editor]++****************************************************************++From: Jean-Pierre Rosen+Sent: Monday, February 14, 2011 2:19 AM++> We also allow aspect specifications on renaming declarations, but+> indicate there are no language-defined aspects that can be specified+> on a renaming.++but the !proposal section still says:++Aspect specification are not permitted on renaming declarations, as that would+seem to break the underlying model of renaming (that properties are the same as+the renamed entity).++****************************************************************++From: Tucker Taft+Sent: Monday, February 14, 2011 8:51 AM++Oops, sorry about that. Once I get embroiled in wording, I always forget to go+back and read the summary/proposal!++[Corrected in version /08.]++****************************************************************++From: Randy Brukardt+Sent: Monday, February 14, 2011 10:37 PM++The following paragraph is under Legality Rules:++The aspect_definition associated with a given aspect_mark may be omitted only+when the aspect_mark identifies an aspect of a boolean type, in which case it is+equivalent to the aspect_definition being specified as True.++but this doesn't seem to have much to do with Legality; it seems more like+Static Semantics to me. (I ask because I was looking for this rule when working+on AI05-0229-1 on Friday, and failed to find it then -- never thought to look in+Legality Rules.)
****************************************************************