CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/04/15 05:29:06 1.15
+++ ai05s/ai05-0229-1.txt 2011/06/07 05:10:01 1.16
@@ -1,10 +1,19 @@
-!standard 13.2(5) 11-04-14 AI05-0229-1/09
+!standard 13.2(5) 11-06-06 AI05-0229-1/10
+!standard 13.11.3(1)
+!standard 13.11.3(2)
+!standard 13.11.3(3)
+!standard 13.11.3(4)
!standard 13.11.3(5)
+!standard 13.11.3(6)
+!standard 13.11.3(7)
+!standard 13.11.3(8)
!standard B.3.3(4)
!standard E.4.1(8)
!standard J.15(0)
!standard K.1(0)
!class Amendment 10-10-25
+!status Amendment 2012 11-06-06
+!status ARG Approved (by Letter Ballot) 9-1-1 11-05-16
!status work item 10-10-25
!status received 10-10-25
!priority Medium
@@ -40,10 +49,10 @@
[Editor's Note: 13.3(5/3), from AI05-0183-1; but we can't put paragraph numbers into
AARM notes. We need this note here because this rule is far away in the standard.]
-A representation pragma or library unit pragma that has a single argument that
-is a local_name may be specified by an aspect_specification, with the entity
-being the local_name. The aspect_definition is expected to be of type Boolean.
-The expression shall be static.
+Any aspect specified by a representation pragma or library unit pragma that
+has a local_name as its single argument may be specified by an aspect_specification,
+with the entity being the local_name. The aspect_definition is expected to be
+of type Boolean. The expression shall be static.
AARM Ramification: The name of the aspect is the same as that of the pragma
(see 13.1), so the aspect_mark is the name of the pragma.
@@ -205,39 +214,10 @@
[This is the only use of No_Return in an Ada predefined package.]
-===pragma Controlled: (the pragma is to be obsolescent)
+===pragma Controlled:
-Change the title of clause 13.11.3 to "Controlling Storage Reclamation".
+Delete the entire subclause 13.11.3.
-Modify 13.11.3(1/2):
-
-{Specifying aspect Controlled to have value True prevents}[Pragma Controlled is
-used to prevent] any automatic reclamation of storage (garbage collection) for
-the objects created by allocators of a given access type.
-
-Delete 13.11.3(2-4). [Now in Annex J.]
-
-Replace 13.11.3(5):
-
- For a non-derived access type, the following language-defined
- representation aspect may be specified:
- Controlled
- The type of aspect Controlled is Boolean.
- If directly specified, the aspect_definition shall be a static expression.
- If not specified (including by inheritance), the aspect is False.
-
-Modify 13.11.3(7):
-
-If {aspect Controlled is True}[a pragma Controlled is specified] for an access
-type with a standard storage pool, then garbage collection is not performed for
-objects in that pool.
-
-Modify 13.11.3(8):
-
-An implementation need not support garbage collection, in which case, {aspect
-Controlled}[a pragma Controlled] has no effect.
-
-
===pragma Unchecked_Union: (the pragma is to be obsolescent)
Change the title of clause B.3.3 to "Unchecked Union Types".
@@ -338,13 +318,13 @@
Replace C.6(10) with the following two paragraphs:
-If one of these aspects is specified for a component_declaration, the declaration
-shall not be inherited. If aspect Independent_Components is specified for a
+If aspect Independent_Components is specified for a
full_type_declaration, the declaration shall be that of an array or record type.
-[These rules are needed to replace the resolution rules of C.6(9/3) for items
-not previously included. We want all components and types to have the "regular"
-aspects. - RLB]
+[This rule is needed to replace the resolution rules of C.6(9/3) for items
+not previously included. We don't need a rule for components as there is no
+way to write an inherited component_declaration. We intend that all components
+and types to have the "regular" aspects. - RLB]
It is illegal to specify the aspect Atomic or Atomic_Components for an object
or type if the implementation cannot support the indivisible reads and writes
@@ -1204,36 +1184,18 @@
Add a new clause to Annex J:
-[Note: The subclauses will be rearranged in alphabetical order - at the last
-moment. Also, these pragmas will be indexed in the pragma Annex L; we don't
-want people to freak out when they can't find pragma Pack or pragma Inline
-there (and it will lead them to the right place).]
+[Note: The subclauses are rearranged in alphabetical order in the core, then
+for each Annex. Also, these pragmas will be indexed in the pragma Annex L;
+we don't want people to freak out when they can't find pragma Pack or
+pragma Inline there (and it will lead them to the right place).]
-J.15 Aspect-related pragmas
+J.15 Aspect-related Pragmas
Pragmas can be used as an alternative to aspect_specifications to specify
certain aspects.
-
-J.15.1 Pragma Pack
-
-Syntax
-The form of a pragma Pack, which is a representation pragma (see 13.1),
-is as follows:
- pragma Pack(*first_subtype_*local_name);
-
-Legality Rules
-
-The first_subtype_local_name of a pragma Pack shall denote a composite
-subtype.
+J.15.1 Pragma Inline
-Static Semantics
-
-Pragma Pack specifies that the Pack aspect (see 13.2) for the type
-denoted by *first_subtype_*local_name has the value True.
-
-J.15.2 Pragma Inline
-
Syntax
The form of a pragma Inline, which is a program unit pragma (see
@@ -1302,7 +1264,7 @@
The name in a pragma Inline may denote more than one entity in the
case of overloading. Such a pragma applies to all of the denoted entities.
-J.15.3 Pragma No_Return
+J.15.2 Pragma No_Return
Syntax
@@ -1322,192 +1284,116 @@
Pragma No_Return specifies that the No_Return aspect (see 6.3.2) for each
procedure denoted by each local_name given in the pragma has the value True.
-J.15.4 Pragma Controlled
+J.15.3 Pragma Pack
Syntax
-The form of a pragma Controlled, which is a representation pragma (see 13.1), is
-as follows:
-
- pragma Controlled(first_subtype_local_name);
+The form of a pragma Pack, which is a representation pragma (see 13.1),
+is as follows:
+ pragma Pack(*first_subtype_*local_name);
Legality Rules
-The first_subtype_local_name of a pragma Controlled shall denote a non-derived
-access subtype.
+The first_subtype_local_name of a pragma Pack shall denote a composite
+subtype.
Static Semantics
-A pragma Controlled specifies that the Controlled aspect (see 13.11.3)
-for the type denoted by *first_subtype_*local_name has the value True.
-
+Pragma Pack specifies that the Pack aspect (see 13.2) for the type
+denoted by *first_subtype_*local_name has the value True.
-J.15.5 Pragma Unchecked_Union
+J.15.4 pragma Storage_Size
Syntax
-
-The form of a pragma Unchecked_Union, which is a representation pragma (see
-13.1), is as follows:
-
- pragma Unchecked_Union (first_subtype_local_name);
-
-Legality Rules
-
-The first_subtype_local_name of a pragma Unchecked_Union shall denote an
-unconstrained discriminated record subtype having a variant_part.
-
-Static Semantics
-A pragma Unchecked_Union specifies that the Unchecked_Union aspect (see B.3.3)
-for the type denoted by *first_subtype_*local_name has the value True.
-
+The form of a pragma Storage_Size is as follows:
-J.15.6 Pragma Asynchronous
+ pragma Storage_Size(expression);
-Syntax
+A pragma Storage_Size is allowed only immediately within a task_definition.
-The form of a pragma Asynchronous, which is a representation pragma (see 13.1),
-is as follows:
+Name Resolution Rules
- pragma Asynchronous(local_name);
+The expression of a pragma Storage_Size is expected to be of any integer type.
Static Semantics
-For an implementation that supports Annex E, a pragma Asynchronous specifies
-that the Asynchronous aspect (see E.4.1) for the procedure or type denoted by
-local_name has the value True.
-
-Legality Rules
-
-The local_name of a pragma Asynchronous shall denote a declaration that may have
-aspect Asynchronous specified.
+The pragma Storage_Size sets the Storage_Size aspect (see 13.3) of the type defined
+by the immediately enclosing task_definition to the value of the expression of the
+pragma.
-J.15.7 Pragma Priority and Pragma Interrupt_Priority
+J.15.5 Interfacing pragmas
-Syntax
+An interfacing pragma is a representation pragma that is one of the pragmas Import,
+Export, or Convention. Their forms are as follows:
-The form of a pragma Priority is as follows:
+ pragma Import(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
- pragma Priority(expression);
+ pragma Export(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
-The form of a pragma Interrupt_Priority is as follows:
+ pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);
- pragma Interrupt_Priority[(expression)];
+For pragmas Import and Export, the argument for Link_Name shall not be given without
+the pragma_argument_identifier unless the argument for External_Name is given.
Name Resolution Rules
-The expected type for the expression in a Priority or Interrupt_Priority pragma
-is Integer.
+The expected type for a external_name_string_expression and a link_name_string_expression
+in an interfacing pragma is String.
Legality Rules
-
-A Priority pragma is allowed only immediately within a task_definition, a
-protected_definition, or the declarative_part of a subprogram_body. An
-Interrupt_Priority pragma is allowed only immediately within a task_definition
-or a protected_definition. At most one such pragma shall appear within a given
-construct.
-
-For a Priority pragma that appears in the declarative_part of a subprogram_body,
-the expression shall be static, and its value shall be in the range of
-System.Priority.
-
-Static Semantics
-
-For an implementation that supports Annex D, a pragma Priority specifies the
-value of the Priority aspect (see D.1) and a pragma Interrupt_Priority specifies
-the value of the Interrupt_Priority aspect as follows:
-* If the pragma appears in a task_definition, the expression is associated with
- the aspect for the task type or single_task_definition that contains the
- pragma;
-* If the pragma appears in a protected_definition, the expression is associated
- with the aspect for the protected type or single_protected_definition that
- contains the pragma;
-* If the pragma appears in the declarative part of a subprogram_body, the
- expression is associated with the aspect for the subprogram that contains the
- pragma.
-
-If there is no expression in an Interrupt_Priority pragma, the
-Interrupt_Priority aspect has the value Interrupt_Priority'Last.
-
-J.15.8 pragma CPU
-
-AARM Discussion: This pragma is born obsolescent; it is defined to provide
-consistency with existing real-time pragmas.
-
-Syntax
-
-The form of a pragma CPU is as follows:
- pragma CPU (expression);
-
-Name Resolution Rules
-The expected type for the expression of a pragma CPU is
-System.Multiprocessors.CPU_Range.
+The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).
-Legality Rules
+A pragma Import shall be the completion of a declaration.
-A CPU pragma is allowed only immediately within a task_definition, or the
-declarative_part of a subprogram_body. At most one such pragma shall appear
-within a given construct.
+The external_name_string_expression and link_name_string_expression of a pragma Import
+or Export shall be static.
-For a CPU pragma that appears in the declarative_part of a subprogram_body, the
-expression shall be static.
+The local_name of of each of these pragmas shall denote a declaration that may have
+the similarly named aspect specified.
Static Semantics
-
-For an implementation that supports Annex D, a pragma CPU specifies the value of
-the CPU aspect (see D.16). If the pragma appears in a task_definition, the
-expression is associated with the aspect for the task type or
-single_task_definition that contains the pragma; otherwise, the expression is
-associated with the aspect for the subprogram that contains the pragma.
-
-J.15.9 pragma Relative_Deadline
-
-Syntax
-
-The form of a pragma Relative_Deadline is as follows:
- pragma Relative_Deadline (relative_deadline_expression);
-
-Name Resolution Rules
-The expected type for relative_deadline_expression is Real_Time.Time_Span.
+An interfacing pragam specifies various aspects of the entity denoted by the
+local_name as follows:
-Legality Rules
+* The Convention aspect (see B.1) is convention_identifier.
-A Relative_Deadline pragma is allowed only immediately within a task_definition
-or the declarative_part of a subprogram_body. At most one such pragma shall
-appear within a given construct.
+* A pragma Import specifies that the Import aspect (see B.1) is True.
-Static Semantics
+* A pragma Export specifies that the Export aspect (see B.1) is True.
-For an implementation that supports Annex D, a pragma Relative_Deadline
-specifies the value of the Relative_Deadline aspect (see D.2.6). If the pragma
-appears in a task_definition, the expression is associated with the aspect for
-the task type or single_task_definition that contains the pragma; otherwise, the
-expression is associated with the aspect for the subprogram that contains the
-pragma.
+* For both pragma Import and Export, if an
+ external name is given in the pragma, the External_Name aspect
+ is specified to be external_name_string_expression. If a link name
+ is given in the pragma, the Link_Name aspect is specified to be the
+ link_name_string_expression.
-J.15.10 pragma Storage_Size
+J.15.6 Pragma Unchecked_Union
Syntax
-
-The form of a pragma Storage_Size is as follows:
- pragma Storage_Size(expression);
+The form of a pragma Unchecked_Union, which is a representation pragma (see
+13.1), is as follows:
-A pragma Storage_Size is allowed only immediately within a task_definition.
+ pragma Unchecked_Union (first_subtype_local_name);
-Name Resolution Rules
+Legality Rules
-The expression of a pragma Storage_Size is expected to be of any integer type.
+The first_subtype_local_name of a pragma Unchecked_Union shall denote an
+unconstrained discriminated record subtype having a variant_part.
Static Semantics
-The pragma Storage_Size sets the Storage_Size aspect of the type defined by the
-immediately enclosing task_definition to the value of the expression of the
-pragma.
+A pragma Unchecked_Union specifies that the Unchecked_Union aspect (see B.3.3)
+for the type denoted by *first_subtype_*local_name has the value True.
-J.15.11 Pragmas Interrupt_Handler and Attach_Handler
+J.15.7 Pragmas Interrupt_Handler and Attach_Handler
The form of a pragma Interrupt_Handler is as follows:
pragma Interrupt_Handler(handler_name);
@@ -1541,7 +1427,7 @@
the protected procedure handler_name to have the value of the given expression
[Redundant: as evaluated at object creation time].
-J.15.12 Shared variable pragmas
+J.15.8 Shared variable pragmas
Syntax
@@ -1581,66 +1467,139 @@
The local_name of of each of these pragmas shall denote a declaration that may have
the similarly named aspect specified.
-
-J.15.13 Interfacing pragmas
-
-An interfacing pragma is a representation pragma that is one of the pragmas Import,
-Export, or Convention. Their forms are as follows:
- pragma Import(
- [Convention =>] convention_identifier, [Entity =>] local_name
- [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
+J.15.9 pragma CPU
- pragma Export(
- [Convention =>] convention_identifier, [Entity =>] local_name
- [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
+AARM Discussion: This pragma is born obsolescent; it is defined to provide
+consistency with existing real-time pragmas.
- pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);
+Syntax
-For pragmas Import and Export, the argument for Link_Name shall not be given without
-the pragma_argument_identifier unless the argument for External_Name is given.
+The form of a pragma CPU is as follows:
+ pragma CPU (expression);
Name Resolution Rules
-The expected type for a external_name_string_expression and a link_name_string_expression
-in an interfacing pragma is String.
+The expected type for the expression of a pragma CPU is
+System.Multiprocessors.CPU_Range.
Legality Rules
-
-The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).
-
-A pragma Import shall be the completion of a declaration.
-The external_name_string_expression and link_name_string_expression of a pragma Import
-or Export shall be static.
+A CPU pragma is allowed only immediately within a task_definition, or the
+declarative_part of a subprogram_body. At most one such pragma shall appear
+within a given construct.
-The local_name of of each of these pragmas shall denote a declaration that may have
-the similarly named aspect specified.
+For a CPU pragma that appears in the declarative_part of a subprogram_body, the
+expression shall be static.
Static Semantics
-An interfacing pragam specifies various aspects of the entity denoted by the
-local_name as follows:
+For an implementation that supports Annex D, a pragma CPU specifies the value of
+the CPU aspect (see D.16). If the pragma appears in a task_definition, the
+expression is associated with the aspect for the task type or
+single_task_definition that contains the pragma; otherwise, the expression is
+associated with the aspect for the subprogram that contains the pragma.
-* The Convention aspect (see B.1) is convention_identifier.
+[Editor's note: J.15.10 is in AI05-0167-1.]
-* A pragma Import specifies that the Import aspect (see B.1) is True.
+J.15.11 Pragmas Priority and Interrupt_Priority
-* A pragma Export specifies that the Export aspect (see B.1) is True.
+Syntax
-* For both pragma Import and Export, if an
- external name is given in the pragma, the External_Name aspect
- is specified to be external_name_string_expression. If a link name
- is given in the pragma, the Link_Name aspect is specified to be the
- link_name_string_expression.
+The form of a pragma Priority is as follows:
+ pragma Priority(expression);
+The form of a pragma Interrupt_Priority is as follows:
+ pragma Interrupt_Priority[(expression)];
+Name Resolution Rules
+The expected type for the expression in a Priority or Interrupt_Priority pragma
+is Integer.
-Rearrange Annex K:
+Legality Rules
+
+A Priority pragma is allowed only immediately within a task_definition, a
+protected_definition, or the declarative_part of a subprogram_body. An
+Interrupt_Priority pragma is allowed only immediately within a task_definition
+or a protected_definition. At most one such pragma shall appear within a given
+construct.
+
+For a Priority pragma that appears in the declarative_part of a subprogram_body,
+the expression shall be static, and its value shall be in the range of
+System.Priority.
+
+Static Semantics
+
+For an implementation that supports Annex D, a pragma Priority specifies the
+value of the Priority aspect (see D.1) and a pragma Interrupt_Priority specifies
+the value of the Interrupt_Priority aspect as follows:
+* If the pragma appears in a task_definition, the expression is associated with
+ the aspect for the task type or single_task_definition that contains the
+ pragma;
+* If the pragma appears in a protected_definition, the expression is associated
+ with the aspect for the protected type or single_protected_definition that
+ contains the pragma;
+* If the pragma appears in the declarative part of a subprogram_body, the
+ expression is associated with the aspect for the subprogram that contains the
+ pragma.
+
+If there is no expression in an Interrupt_Priority pragma, the
+Interrupt_Priority aspect has the value Interrupt_Priority'Last.
+
+J.15.12 pragma Relative_Deadline
+
+Syntax
+The form of a pragma Relative_Deadline is as follows:
+ pragma Relative_Deadline (relative_deadline_expression);
+
+Name Resolution Rules
+
+The expected type for relative_deadline_expression is Real_Time.Time_Span.
+
+Legality Rules
+
+A Relative_Deadline pragma is allowed only immediately within a task_definition
+or the declarative_part of a subprogram_body. At most one such pragma shall
+appear within a given construct.
+
+Static Semantics
+
+For an implementation that supports Annex D, a pragma Relative_Deadline
+specifies the value of the Relative_Deadline aspect (see D.2.6). If the pragma
+appears in a task_definition, the expression is associated with the aspect for
+the task type or single_task_definition that contains the pragma; otherwise, the
+expression is associated with the aspect for the subprogram that contains the
+pragma.
+
+J.15.13 Pragma Asynchronous
+
+Syntax
+
+The form of a pragma Asynchronous, which is a representation pragma (see 13.1),
+is as follows:
+
+ pragma Asynchronous(local_name);
+
+Static Semantics
+
+For an implementation that supports Annex E, a pragma Asynchronous specifies
+that the Asynchronous aspect (see E.4.1) for the procedure or type denoted by
+local_name has the value True.
+
+Legality Rules
+
+The local_name of a pragma Asynchronous shall denote a declaration that may have
+aspect Asynchronous specified.
+
+
+
+
+Rearrange Annex K:
+
Annex K
(informative)
@@ -1728,7 +1687,8 @@
----------------
-Pragmas that could be Boolean operational or representation aspects:
+Pragmas that could be Boolean operational or representation aspects (subject to
+other concerns):
pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3.
@@ -1780,7 +1740,7 @@
----------------
Pragmas that could be other (normal) operational or representation aspects
-using the mechanism for "identifiers specific to an aspect":
+using the mechanism for "identifiers specific to an aspect":
pragma Convention([Convention =>] convention_identifier,[Entity =>]
local_name); - See B.1.
@@ -1846,11 +1806,67 @@
pragma Unsuppress(identifier); - See 11.5.
+---------------------------
+
+During the discussion of this AI, the question of the value of pragma Controlled
+came up. As far as we can tell, no implementation supports this pragma and no
+user uses it other than by mistake (believing it does something it does not).
+
+Beyond that, the name is confusing (as it uses the same term as finalization).
+
+Therefore, we decided to drop this pragma completely (rather than turn it into
+an aspect).
+
+!corrigendum 13.11.3(1)
+
+@ddel
+Pragma Controlled is used to prevent any automatic reclamation of storage (garbage
+collection) for the objects created by @fa<allocator>s of a given access type.
+
+!corrigendum 13.11.3(2)
+
+@ddel
+@xindent<The form of a pragma Controlled is as follows:>
+
+!corrigendum 13.11.3(3)
+
+@ddel
+@xindent<@b<pragma> Controlled(@i<first_subtype_>@fa<local_name>)>
+!corrigendum 13.11.3(4)
+@ddel
+The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Controlled shall denote a
+non-derived access subtype.
+
+!corrigendum 13.11.3(5)
+
+@ddel
+A @fa<pragma> Controlled is a representation pragma that specifies the controlled
+aspect of representation.
+
+!corrigendum 13.11.3(6)
+
+@ddel
+@i<Garbage collection> is a process that automatically reclaims storage, or moves
+objects to a different address, while the objects still exist.
+
+!corrigendum 13.11.3(7)
+
+@ddel
+If a @fa<pragma> Controlled is specified for an access type with a standard storage pool,
+then garbage collection is not performed for objects in that pool.
+
+!corrigendum 13.11.3(8)
+
+@ddel
+An implementation need not support garbage collection, in which case, a pragma Controlled
+has no effect.
+
+
!ACATS test
-ACATS tests would be needed for this aspect.
+ACATS tests would be needed to check that all of these aspects can be specified.
!appendix
@@ -4222,5 +4238,995 @@
I agree with Tuck, and I don't see a need to force consistency, the choice of
which of these sounds nicer depends on the circumstance.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, May 15, 2011 11:31 AM
+
+[The appropriate part of a longer message - Editor.]
+
+AI05-0229-1/09 Specifiable aspects
+ [Changes from phone meeting: moved xxx_components aspect to be array type only;
+ removed Preelaborable_Initialization (it will remain a pragma); added legality
+ rules to prevent various aspects from being specified on interfaces; added
+ change of pragma Convention to an aspect in predefined packages.]
+ Approve ______ Disapprove __X____ Abstain _______
+
+=====================
+
+> A representation pragma or library unit pragma that has a single
+> argument that is a local_name may be specified by an
+> aspect_specification, with the entity being the local_name. The aspect_definition is expected to be of type Boolean.
+> The expression shall be static.
+
+surely it is not a pragma that is specified. (and stacking the "that"s 3-deep is
+not nice). Suggested Rewrite:
+
+Any aspect specified by a representation pragma or library unit pragma that has
+a local_name as its single argument may be specified by an aspect_specification,
+with the entity being the local_name. The aspect_definition is expected to be of
+type Boolean. The expression shall be static.
+
+> If directly specified, the aspect_definition shall be a static expression.
+> [Redundant: This aspect is never inherited;] ....
+
+Why is this redundant? 13.1 (15/1) says exactly the opposite. It is a
+representational aspect after all. Same comment for Inline and possibly others.
+
+> Replace C.6(10) with the following two paragraphs:
+> If one of these aspects is specified for a component_declaration, the
+> declaration shall not be inherited.
+
+Ambiguous wording. Can be read as an inheritance rule (hiding the
+component) rather than an aspect rule. And: how can I refer to a syntactic
+component_declaration when the component/declaration is inherited?
+
+Suggested rewrite:
+"It is illegal to specify any one of these aspects for an inherited component."
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, May 15, 2011 2:54 PM
+
+[The appropriate part of a longer message - Editor.]
+
+> AI05-0229-1/09 Specifiable aspects
+> [Changes from phone meeting: moved xxx_components aspect to be array type only;
+> removed Preelaborable_Initialization (it will remain a pragma);added legality
+> rules to prevent various aspects from being specified on interfaces; added
+> change of pragma Convention to an aspect in predefined packages.]
+> Approve ___X___ Disapprove ______ Abstain _______
+
+Editorial Comment: In the AI, in the wording section of the AI, there is
+discussion stating the P_I is not appropriate as an aspect and will only be
+available as a pragma. However, in the discussion section under the heading
+"Pragmas that could be Boolean operational or Representational aspects:" it
+still lists P_I.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 17, 2011 2:11 AM
+
+...
+> > A representation pragma or library unit pragma that has a single
+> > argument that is a local_name may be specified by an
+> > aspect_specification, with the entity being the local_name. The
+> > aspect_definition is expected to be of type Boolean.
+> > The expression shall be static.
+>
+> surely it is not a pragma that is specified. (and stacking the "that"s
+> 3-deep is not nice). Suggested Rewrite:
+>
+> Any aspect specified by a representation pragma or library unit pragma
+> that has a local_name as its single argument may be specified by an
+> aspect_specification, with the entity being the local_name. The
+> aspect_definition is expected to be of type Boolean. The expression
+> shall be static.
+
+Looks like an improvement to me, so I used it.
+
+> > If directly specified, the aspect_definition shall be a static expression.
+> > [Redundant: This aspect is never inherited;] ....
+>
+> Why is this redundant? 13.1 (15/1) says exactly the opposite.
+> It is a representational aspect after all. Same comment for Inline and
+> possibly others.
+
+I presume you are talking about No_Return here (you didn't say). Anyway, that is
+a subprogram aspect; 13.1(15/1) is only talking about type aspects and derived
+types. There is no inheritance defined for other kinds of entities. As I
+mentioned in another message, maybe there should have been, but in general we
+don't need it for subprogram aspects.
+
+Inline in particular is *not* inherited. And unlike No_Return, there is no
+mechanism for it to be inherited. (Since it applies effectively to bodies, there
+isn't any reason for it to be inherited, either.)
+
+Similarly, preconditions and postconditions aren't inherited. (Class-wide ones
+"apply" to descendants, but they aren't inherited either; this allows new ones
+to be additively specified, which is what we want.)
+
+> > Replace C.6(10) with the following two paragraphs:
+> > If one of these aspects is specified for a component_declaration,
+> > the declaration shall not be inherited.
+>
+> Ambiguous wording. Can be read as an inheritance rule (hiding the
+> component) rather than an aspect rule. And: how can I refer to a
+> syntactic component_declaration when the component/declaration is
+> inherited?
+>
+> Suggested rewrite:
+> "It is illegal to specify any one of these aspects for an inherited
+> component."
+
+I think you were right with your first idea: it's not possible to specify an
+aspect on an inherited component_declaration, because it is not syntactically
+there. I was too literal in my translation of the old rules - that was a problem
+when the name (alone) is specified in a pragma, but not when the entire syntax
+has to appear (because that, by definition, is not inherited). So I just deleted
+the sentence completely and fixed up the corresponding editor's note.
+
+--------------------
+
+I'm a bit surprised that you voted against this AI, as none of the technical
+objections rise much beyond editorial questions. Was there some other objection
+that you didn't voice??
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, May 17, 2011 12:16 PM
+
+> I'm a bit surprised that you voted against this AI, as none of the technical
+> objections rise much beyond editorial questions. Was there some other
+> objection that you didn't voice??
+
+Not at the time, but now I have. All of the pragmas turned into
+respresentational aspects, none into operational aspects; the summary suggests
+that there are operational ones, too. (A consequence of cut-and-paste or
+deliberate?) Certainly Inline or No_Return do strike me as being perfectly
+operational aspects (which, incidently, are specified as non-inherited, which
+would justify the "Redundant"-phrases ;-))
+
+The AI started out with me as an "Approve with comment", but we did not have
+this category. Also, I was not sure whether the "Redundant" comments would not
+merit further discussion as to why these were redundant. I still think that, for
+representational attributes, they are not, because out of not specifying
+inheritance of an aspect at all one cannot deduce non-inheritance, strictly
+speaking. (Just because nothing is said about it, you cannot conclude that I am
+not German.) But I guess, this is not the important discussion to have.
+
+I would like to further discuss whether they are operational aspects.
+A simple answer would be to make them operational aspects, along with many
+others. In fact, apart from Storage_Size and most of the boolean attributes, the
+listed pramas have the flavor of operational rather than representational
+aspects.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 17, 2011 2:30 PM
+
+> > I'm a bit surprised that you voted against this AI, as none of the technical
+> > objections rise much beyond editorial questions. Was there some
+> > other objection that you didn't voice??
+>
+> Not at the time, but now I have. All of the pragmas turned into
+> respresentational aspects, none into operational aspects; the summary
+> suggests that there are operational ones, too. (A consequence of
+> cut-and-paste or deliberate?)
+
+I think the summary was written first; it should be fixed.
+
+Anyway, the main issue is that Ada has no concept of "operational pragma", only
+of "representation pragma". In order for any of these to be operational aspects,
+the pragma classification would need to be changed, which would require a bunch
+of extra wording in 13.1 (so that the important rules against duplication would
+clearly apply).
+
+This would have been doable, but I was trying (as usual) to make the minimum
+changes here.
+
+> Certainly Inline or No_Return do strike me as being perfectly
+> operational aspects (which, incidently, are specified as
+> non-inherited, which would justify the "Redundant"-phrases ;-))
+
+No_Return is currently defined as a representation pragma. Changing it to
+something else seemed like churn.
+
+Inline is a library unit pragma, so it wouldn't have that problem. But
+"inlining" seemed very representational to me (it has to do with the
+representation of the body); the idea of operational aspects was for stuff that
+didn't have a direct impact on the form of an entity. So this seems more
+operational than representational.
+
+> The AI started out with me as an "Approve with comment", but we did
+> not have this category. Also, I was not sure whether the "Redundant"
+> comments would not merit further discussion as to why these were
+> redundant. I still think that, for representational attributes, they
+> are not, because out of not specifying inheritance of an aspect at all
+> one cannot deduce non-inheritance, strictly speaking.
+> (Just because nothing is said about it, you cannot conclude that I am
+> not German.) But I guess, this is not the important discussion to
+> have.
+
+My opinion is that if the RM doesn't explicitly state something, then it doesn't
+exist. If we start "inferring" semantics from wording about other kinds of
+entities, we are going to have a lot of trouble. Perhaps 13.1 should have a
+sentence saying that there is no inheritance unless described explicitly, but
+that seems to me to do without saying. We don't have to say that a float type is
+not a descendant of type Integer! (Or more generally, we don't have to say that
+a float type is not a descendant of any type other than root_real.) The meaning
+of "inheritance" is exactly what the RM says it is, and nothing more.
+
+It is a common problem in the wording that someone assumes "inheritance" or
+"pragma applies" or terms like that are usable outside of their existing narrow
+contexts. There have been a lot of fixes like that (Adam complaining about that
+is what started AI05-0215-1, to take one recent example).
+
+> I would like to further discuss whether they are operational aspects.
+> A simple answer would be to make them operational aspects, along with
+> many others. In fact, apart from Storage_Size and most of the boolean
+> attributes, the listed pramas have the flavor of operational rather
+> than representational aspects.
+
+That might be, but they are almost all previously defined as representation
+pragmas. And we don't have a concept of "operational pragma", so changing these
+seemed like churn to me.
+
+Also note that for types, "operational aspects" are allowed on private types,
+"representational aspects" are not. For things like Priority, we don't want to
+have to define rules for allowing them on private types, and I don't think we
+want to muddle the rules by allowing some but not all operational aspects on
+private types (that would require quite a bit of change in 13.1). So they too
+end up as representational aspects.
+
+As I mentioned in reply to Tucker, it would make a lot of sense to have
+additional flavors of aspects (categorization aspects don't seem much like
+either of the existing categories, for instance), but that is pretty complicated
+to define and doesn't seem worth the effort.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, May 2, 2011 9:44 PM
+
+[The appropriate part of a longer message - Editor.]
+
+AI05-0190-1/11 Global storage pool controls
+ [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.]
+ Approve __X____ Disapprove ______ Abstain _______
+ Comments:
+ Should we move pragma Controlled to the obsolescent Annex?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 2, 2011 10:32 PM
+
+> Should we move pragma Controlled to the obsolescent Annex?
+
+AI05-0229-1 does that.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, May 3, 2011 2:04 PM
+
+What I actually meant was to move the whole kit-and-kaboodle to Annex J. That
+is, move the Controlled aspect, pragma, etc. to Annex J. In other words,
+13.11.3 would disappear and reappear in Annex J. Perhaps that is too radical?
+
+Do *any* Ada compilers support the "Controlled" pragma/aspect?
+Our Ada->Java-byte-code compiler supports garbage collection, but we don't have
+any way of turning it off.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 3, 2011 2:51 PM
+
+> What I actually meant was to move the whole kit-and-kaboodle to Annex
+> J. That is, move the Controlled aspect, pragma, etc. to Annex J. In
+> other words, 13.11.3 would disappear and reappear in Annex J. Perhaps
+> that is too radical?
+
+It's pretty radical for the last minute.
+
+OTOH, as a pragma, we don't even have to move it to annex J. If we don't want
+the feature anymore, it can just go "poof"! And I agree that it doesn't do
+anything useful (other than perhaps promise capabilities that can't really be
+delivered in stock Ada - we don't have a permission to finalize early, so
+anything that might be controlled cannot be garbage collected).
+
+We have plenty of precident for "poof" in Ada 95 (pragma Memory_Size and
+System_Name, also never implemented).
+
+> Do *any* Ada compilers support the "Controlled" pragma/aspect?
+> Our Ada->Java-byte-code compiler supports garbage collection, but we
+> don't have any way of turning it off.
+
+I don't know of any. That suggests "poof" is a good option...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 6, 2011 12:47 AM
+
+Tucker has suggested that we consider removing pragma Controlled from the core (and as a side-effect, not defining it as an aspect). He asks the question "Do *any* Ada compilers support the "Controlled" pragma/aspect?". I don't know of any.
+
+As a pragma, we wouldn't even need to move this to Annex J; it could simply
+disappear.
+
+Probably the only real benefit of 13.11.3 is that it gets the term "garbage
+collection" in the Standard and index, so that everyone can find out that Ada
+doesn't have it. ;-)
+
+Anyway, it is pretty late to consider this, but since I haven't yet done the
+work to "aspectize" it in the draft Standard, we still can move the whole thing
+to Annex J or delete it outright if we want.
+
+So here's another straw poll:
+
+Please rank these options from 1 to 4, with 1 being the most preferred and 4
+being the least.
+
+_______ Remove 13.11.3 (Pragma Controlled) completely from the standard.
+
+_______ Move the entire contents of 13.11.3 to Annex J, do not make it an
+ aspect.
+
+_______ Move the entire contents of 13.11.3 to Annex J, but still make it an
+ aspect.
+
+_______ Make pragma Controlled into an aspect, move just the pragma to Annex J
+ (the solution currently approved in AI05-0229-1).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 6, 2011 12:47 AM
+
+And here's my ballot:
+
+...
+> Please rank these options from 1 to 4, with 1 being the most preferred
+> and 4 being the least.
+>
+> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the
+> standard.
+>
+> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
+> it an aspect.
+>
+> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
+> make it an aspect.
+>
+> ___4____ Make pragma Controlled into an aspect, move just the pragma
+> to Annex J (the solution currently approved in AI05-0229-1).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, May 6, 2011 4:25 AM
+
+> Tucker has suggested that we consider removing pragma Controlled from
+> the core (and as a side-effect, not defining it as an aspect). He asks
+> the question "Do *any* Ada compilers support the "Controlled"
+> pragma/aspect?". I don't know of any.
+
+Not now, but it is always something that might be done in the future
+>
+> As a pragma, we wouldn't even need to move this to Annex J; it could
+> simply disappear.
+>
+> Probably the only real benefit of 13.11.3 is that it gets the term
+> "garbage collection" in the Standard and index, so that everyone can
+> find out that Ada doesn't have it. ;-)
+>
+> Anyway, it is pretty late to consider this, but since I haven't yet
+> done the work to "aspectize" it in the draft Standard, we still can
+> move the whole thing to Annex J or delete it outright if we want.
+>
+> So here's another straw poll:
+>
+> Please rank these options from 1 to 4, with 1 being the most preferred
+> and 4 being the least.
+
+My preference isn't even here, which is do nothing at all. this is undoubtedly
+what GNAT will do anyway.
+
+I think it is plain silly to make this into an aspect, extra work for
+implementations and the standard for absolutely no gain whatever.
+
+Any of the solutions above has the disadvantage of being extra work I don't like
+any of them
+
+>>
+>> __2_____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
+
+Well easy enough to implement, any implementation that followed suit would be
+wasting its time, certainly we wouldn't bother in GNAT, though I guess this
+technically would force us to add to the Annex M documentation.
+
+>>
+>> __1_____ Move the entire contents of 13.11.3 to Annex J, do not make
+>> it an aspect.
+
+Well that's zero work to implement and document, and I guess minimal work for
+the standard effort, so if we have to choose one of these, this is the best
+
+>>
+>> __3_____ Move the entire contents of 13.11.3 to Annex J, but still
+>> make it an aspect.
+
+Better than 4 below, but still wastes everyones time
+
+>>
+>> __4_____ Make pragma Controlled into an aspect, move just the pragma
+>> to Annex J (the solution currently approved in AI05-0229-1).
+
+Wastes everyones time
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, May 6, 2011 5:21 AM
+
+> Please rank these options from 1 to 4, with 1 being the most preferred
+> and 4 being the least.
+>
+> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
+>
+> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
+> it an aspect.
+>
+> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
+> make it an aspect.
+>
+> ____4___ Make pragma Controlled into an aspect, move just the pragma
+> to Annex J (the solution currently approved in AI05-0229-1).
+>
+
+I think pragma Controlled is actively harmful, I only saw it used by people who
+did not understand its (none) effect, and who were expecting from it properties
+that it did not ensure.
+
+Making it into an aspect would be some kind of blessing that it does mean
+something - which it doesn't.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, May 6, 2011 5:53 AM
+
+> And here's my ballot:
+>
+> ...
+> > Please rank these options from 1 to 4, with 1 being the most
+> > preferred and 4 being the least.
+> >
+> > ___1____ Remove 13.11.3 (Pragma Controlled) completely from the
+> > standard.
+> >
+> > ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
+> > it an aspect.
+> >
+> > ___3____ Move the entire contents of 13.11.3 to Annex J, but still
+> > make it an aspect.
+> >
+> > ___4____ Make pragma Controlled into an aspect, move just the pragma
+> > to Annex J (the solution currently approved in AI05-0229-1).
+
+My vote is identical to Randy's, above.
+
+I think the idea of (1) is that implementations will keep doing exactly what
+they're doing, presumably keeping pragma Controlled as an impl-def pragma.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, May 6, 2011 5:55 AM
+
+> Please rank these options from 1 to 4, with 1 being the most preferred
+> and 4 being the least.
+>
+> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
+>
+> ____2___ Move the entire contents of 13.11.3 to Annex J, do not make
+> it an aspect.
+>
+> _____3__ Move the entire contents of 13.11.3 to Annex J, but still
+> make it an aspect.
+>
+> ____4___ Make pragma Controlled into an aspect, move just the pragma
+> to Annex J (the solution currently approved in AI05-0229-1).
+
+Yes, lets get rid of the wretched thing. That saves 4 lines in my book.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, May 6, 2011 7:34 AM
+
+> Tucker has suggested that we consider removing pragma Controlled from
+> the core (and as a side-effect, not defining it as an aspect). He asks
+> the question "Do *any* Ada compilers support the "Controlled"
+> pragma/aspect?". I don't know of any.
+>
+> As a pragma, we wouldn't even need to move this to Annex J; it could
+> simply disappear.
+>
+> Probably the only real benefit of 13.11.3 is that it gets the term
+> "garbage collection" in the Standard and index, so that everyone can
+> find out that Ada doesn't have it. ;-)
+>
+> Anyway, it is pretty late to consider this, but since I haven't yet
+> done the work to "aspectize" it in the draft Standard, we still can
+> move the whole thing to Annex J or delete it outright if we want.
+>
+> So here's another straw poll:
+>
+> Please rank these options from 1 to 4, with 1 being the most preferred
+> and 4 being the least.
+>
+> __1_____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
+>
+> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
+> it an aspect.
+>
+> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
+> make it an aspect.
+>
+> ___4____ Make pragma Controlled into an aspect, move just the pragma
+> to Annex J (the solution currently approved in AI05-0229-1).
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Friday, May 6, 2011 9:46 AM
+
+Get rid of it.
+
+___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
+
+____2___ Move the entire contents of 13.11.3 to Annex J, do not make it an
+aspect.
+
+___3____ Move the entire contents of 13.11.3 to Annex J, but still make it an
+aspect.
+
+___4____ Make pragma Controlled into an aspect, move just the pragma to Annex
+J (the solution currently approved in AI05-0229-1).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, May 6, 2011 11:26 AM
+
+>> Please rank these options from 1 to 4, with 1 being the most
+>> preferred and 4 being the least.
+>>
+>> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
+>>
+>> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
+>> it an aspect.
+>>
+>> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
+>> make it an aspect.
+>>
+>> ____4___ Make pragma Controlled into an aspect, move just the pragma
+>> to Annex J (the solution currently approved in AI05-0229-1).
+>>
+>
+> I think pragma Controlled is actively harmful, I only saw it used by
+> people who did not understand its (none) effect, and who were
+> expecting from it properties that it did not ensure.
+
+OK, I find that a convincing argument, I change my vote to agree with the above
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, May 6, 2011 12:56 PM
+
+Edmond Schonberg wrote:
+> Get rid of it.
+
+Agreed.
+
+My vote is identical to Bob's, below.
+
+Bob Duff wrote:
+> My vote is identical to Randy's, above.
+
+[Editor's note: the above is the unedited message. Any infinite recursion is
+the responsibility of the original author. ;-)]
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, May 6, 2011 1:20 PM
+
+I'm also fine with jettisoning it, and my vote matches others.
+
+Looks like we have a true consensus.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, May 6, 2011 7:03 PM
+
+My vote is identical to Randy's and the others
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, May 11, 2011 11:54 AM
+
+AI05-0229-1, Specifiable aspects says:
+
+ ===pragma Interrupt_Priority, Priority (the pragmas are to be obsolescent)
+
+ [Editor's Note: I'd much prefer that there was only one aspect here, probably
+ named "Base_Priority", but the rules about converting to subtype Any_Priority
+ vs. to subtype Priority at evaluation time force two aspects. That's because
+ these aspects are expressions that are evaluated when the task (or protected)
+ object is elaborated, not values evaluated at the freezing point. Personally,
+ I'd drop the two subtypes, but one presumes that there is some value to the
+ bifrucation and in any case it is 30 years too late for that.]
+ ^^^^^^^^ Less than 20 years --
+ Interrupt_Priority
+ was added in Ada 95.
+
+The split was discussed heavily at the time, and everybody seemed to agree that
+it's a good idea to flag interrupt priorities in a special way. You don't want
+to allow "pragma Priority(99)" if 99 just happens to be an interrupt level.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, May 11, 2011 11:54 AM
+
+Right, I agree with that decision and disagree with Randy.
+
+Btw, this silly (IMO) business of moving these pragmas to obsolescent status is
+harmless (except for creating extra work) unless they are included in
+No_Obsolescent_Features, in which case we have an unacceptable incompatibility
+on our hands.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, May 12, 2011 8:31 AM
+
+I was rather uncomfortable with this change. I don't remember, but I probably
+voted against it, or abstained.
+
+It is implementation defined whether No_Obsolescent_Features gripes about these
+pragmas. A gratuitous non-portability, IMHO, but relatively harmless.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, May 12, 2011 8:39 AM
+
+Definitely gratuitous, but also irrelevant, for now implementation defined these
+days mostly means "defined by GNAT" when it comes to Ada 2012. I suggest we NOT
+include these changes in No_Obsolescent_Features for GNAT, there is no point
+whatever in making an incompatible change. Is there really some other Ada 2012
+compiler that strongly wants a different definition? If not, why not just define
+it the way it is going to be, rather than leave this unnecessary non-portability
+around.
+
+To me, we have warnings on unrecognized pragmas in any case in all compilers, so
+there is really no need for this to be included in NOF. If a compiler was so
+stupid as to remove these pragmas in the future, or if the ARG was so stupid as
+to remove them, then the compiler would warn.
+
+To me obsolescent in practice means "defined, required, and will always be
+required, but someone thinks it is a pity that this is the case" :-) :-). The
+whole business of Annex J is gratuitous IMO.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, May 12, 2011 8:45 AM
+
+> I suggest we NOT include these changes in No_Obsolescent_Features for
+> GNAT, ...
+
+I was in charge of implementing AI05-0229-1 in GNAT, and that's exactly the
+decision I made yesterday: I closed the ticket without modifying the behavior of
+No_Obsolescent_Features.
+
+The other part of AI05-0229-1 was to make lots of pragmas and attributes into
+"aspects", which you (Robert) had already mostly done, and I added the rest.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, May 12, 2011 1:07 PM
+
+...
+> It is implementation defined whether No_Obsolescent_Features gripes
+> about these pragmas. A gratuitous non-portability, IMHO, but
+> relatively harmless.
+
+That was done because that was the way that the previous exceptions from the
+restriction are handled. As a practical matter, everything in the annex should
+be rejected when this restriction exists. We're giving a permission to vary from
+that in a few specific cases, but no user should really be depending upon that
+permission being used.
+
+The entire point of the restriction is to allow people to ensure that they
+aren't using old junk in new code; that clearly includes this set of pragmas.
+The exception exists only because people currently using this restriction might
+be impacted.
+
+Really, this restriction (along with a number of other things) should work
+differently depending on what language you are trying to enforce. And in this
+case, what is restricted really should depend on whether the user wants to
+restrict Ada 2005 Annex J (in existing code) or Ada 2012 Annex J (in new code)
+-- and that's separate from which language version is being used to compile the
+code. That clearly requires separate restrictions, something the language cannot
+provide (sadly) because we're not allowed to talk about previous versions in the
+Standard.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, May 12, 2011 1:40 PM
+
+> ...
+>> It is implementation defined whether No_Obsolescent_Features gripes
+>> about these pragmas. A gratuitous non-portability, IMHO, but
+>> relatively harmless.
+>
+> That was done because that was the way that the previous exceptions
+> from the restriction are handled. As a practical matter, everything in
+> the annex should be rejected when this restriction exists. We're
+> giving a permission to vary from that in a few specific cases, but no
+> user should really be depending upon that permission being used.
+
+Well I don't see why not. This is implementation defined, so Annex M is clear on
+the actual effect. For the vast majority (not all, but most) of our users, being
+compatible with other Ada compilers is not an issue, so there is no reason for
+them to follow Randy's advice here. The trouble is that if you make NOF reject
+all obsolescent features, it is useless (due to some very injudicious IMO
+inclusions in annex J).
+
+> The entire point of the restriction is to allow people to ensure that
+> they aren't using old junk in new code; that clearly includes this set
+> of pragmas. The exception exists only because people currently using
+> this restriction might be impacted.
+
+No, it also exists because a reasonable coding style is to reject most of the
+Annex J stuff, but not everything.
+
+Actually to be fair I find the restriction pretty useless, given it rejects the
+use of package ASCII. It's plain horrible to have to with the ISO package,
+especially if you don't allow USE clauses.
+
+In practice in GNAT we have a parallel mechanism -gnatwj, warn on obsolescent
+features. the documentation says:
+
+> In addition to the above cases, warnings are also generated for GNAT
+> features that have been provided in past versions but which have been
+> superseded (typically by features in the new Ada standard).
+> For example, @code{pragma Ravenscar} will be flagged since its
+> function is replaced by @code{pragma Profile(Ravenscar)}.
+>
+> Note that this warning option functions differently from the
+> restriction @code{No_Obsolescent_Features} in two respects.
+> First, the restriction applies only to annex J features.
+> Second, the restriction does flag uses of package @code{ASCII}.
+
+So actually I don't care that much if the pragmas are included, but including
+the pragmas will surely make the restriction even more hopelessly unusable :-)
+
+> Really, this restriction (along with a number of other things) should
+> work differently depending on what language you are trying to enforce.
+> And in this case, what is restricted really should depend on whether
+> the user wants to restrict Ada 2005 Annex J (in existing code) or Ada
+> 2012 Annex J (in new
+> code) -- and that's separate from which language version is being used
+> to compile the code. That clearly requires separate restrictions,
+> something the language cannot provide (sadly) because we're not
+> allowed to talk about previous versions in the Standard.
+
+As I say, the issue to me is what it is sensible to include. I would find a
+compiler that followed randy's advice to be plain annoying. Nothing to do with
+compatibility issues.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, May 12, 2011 2:12 PM
+
+...
+> As I say, the issue to me is what it is sensible to include.
+> I would find a compiler that followed randy's advice to be plain
+> annoying.
+> Nothing to do with compatibility issues.
+
+Nothing new here. You've said this before (that you would find a compiler that
+operates like I think a compiler should is annoying). Hopefully, you'll never
+need to use Janus/Ada. ;-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, May 12, 2011 2:19 PM
+
+Well actually, for us -gnatwj is much more what you want than the restriction. I
+have never understood why people would want to say
+
+ with Ada.Characters.Latin_1
+
+ ...
+
+ Put (Ada.Characters.Latin_1.LF);
+
+instead of the so much more convenient
+
+ Put (ASCII.LF);
+
+SO I would never use the restriction anyway, so I don't really care what it does
+:-)
+
+The trouble is that it *sounds* reasonable to people to avoid obsolescent
+features, so it is all to easy for a requirement of using the restriction to
+creep into coding standards documents.
+
+If such a requirement made people do major surgery on their programs to remove
+all the pragmas and replace by aspects, that would constitute in effect a huge
+extra barrier to the use of Ada 2012.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, May 12, 2011 2:38 PM
+
+...
+> The trouble is that it *sounds* reasonable to people to avoid
+> obsolescent features, so it is all to easy for a requirement of using
+> the restriction to creep into coding standards documents.
+
+I agree with this, but trying to keep "coding standards" reasonable falls
+outside of the perview of the ARG.
+
+> If such a requirement made people do major surgery on their programs
+> to remove all the pragmas and replace by aspects, that would
+> constitute in effect a huge extra barrier to the use of Ada 2012.
+
+Right, which is why I said that you need different restrictions for existing
+code and for new code. Indeed, applying restrictions to existing code is silly
+(I hope no coding standards are doing that), because it means a lot of rework
+for no reason. One could imagine a No_Ada_2005_Obsolescent_Features restriction
+for the purpose of existing systems, but that's outside of what the Standard can
+do.
+
+This is a major problem with most restrictions anyway (given that they apply to
+the entire partition whether you want that or not). Restrictions that are mostly
+style-related (like this one) should only apply to the current unit (it only
+makes sense to use them in new code). But only the portability ones
+(No_Implementation_Pragmas, etc.) get this right. Sigh.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, May 12, 2011 2:40 PM
+
+Just a general comment on restrictions: I can't get too excited about the exact
+meaning of particular restrictions. If the restriction is too restrictive,
+don't use it. If you want a restriction that's different from existing ones,
+ask your vendor to provide one.
+
+Pragma Restrictions is one of my favorite features, precisely because it allows
+to much freedom to choose what you want for your own project.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, May 12, 2011 2:42 PM
+
+> ...
+>> The trouble is that it *sounds* reasonable to people to avoid
+>> obsolescent features, so it is all to easy for a requirement of using
+>> the restriction to creep into coding standards documents.
+>
+> I agree with this, but trying to keep "coding standards" reasonable
+> falls outside of the perview of the ARG.
+
+Not in my opinion, creating annex J had consequences, and it is up to us to
+anticipate and deal with these consequences.
+
+>> If such a requirement made people do major surgery on their programs
+>> to remove all the pragmas and replace by aspects, that would
+>> constitute in effect a huge extra barrier to the use of Ada 2012.
+>
+> Right, which is why I said that you need different restrictions for
+> existing code and for new code. Indeed, applying restrictions to
+> existing code is silly (I hope no coding standards are doing that),
+> because it means a lot of rework for no reason. One could imagine a
+> No_Ada_2005_Obsolescent_Features restriction for the purpose of
+> existing systems, but that's outside of what the Standard can do.
+
+People apply coding standards to existing code all the time. Remember that 178B
+requires you have a comprehebsive coding standard.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, May 12, 2011 2:52 PM
+
+> Just a general comment on restrictions: I can't get too excited about
+> the exact meaning of particular restrictions. If the restriction is
+> too restrictive, don't use it. If you want a restriction that's
+> different from existing ones, ask your vendor to provide one.
+
+I think you probably miss my point. You are assuming that the programmers choose
+the set of restrictions. That's not typically the case. Coding standards for
+178B purposes are typically decided by a separate team who is not as sensible as
+the Duff that wrote the above.
+
+> Pragma Restrictions is one of my favorite features, precisely because
+> it allows to much freedom to choose what you want for your own
+> project.
+
+You is simple in our world, not so simple in the real world
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, May 12, 2011 3:21 PM
+
+> I think you probably miss my point.
+
+Not really. My point is that it's not us Ada language designers placing
+restrictions on people. It's a programmer. Or a project manager. Or a
+committee of beaurocrats. Whatever.
+
+And that's the beauty of pragma Restrictions. We don't need to decide whether
+(say) heap allocation is good or evil. In fact, it's evil in some programs, but
+not others. So we can provide No_Heap_Alloc, and let people choose whether to
+use it. The fact that some folks will choose unwisely is not something I can do
+anything about.
+
+I'm well aware that idiotic coding conventions exist in the real world. But I
+can't fix that fact, so I don't worry about it.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, May 12, 2011 3:34 PM
+
+But you should have worried about it when you created annex J. It was an
+inevitable and undesirable result of creating this annex that these annoying
+coding standards exist.
+
+You can't take actions without thought as to the real world consequences, we
+really can't afford to be THAT far embedded in the ivory tower.
+
+The restrictions we choose shape the way people will write coding standards!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, May 12, 2011 3:46 PM
+
+> But you should have worried about it when you created annex J.
+
+Annex J didn't turn out the way I intended.
+
+And I think I've told you more than once: I have (since Ada 9X
+days) come around to your point of view -- we'd be better off without any Annex
+J.
+
+Also note that I didn't really support moving all those pragmas into Annex J.
****************************************************************
Questions? Ask the ACAA Technical Agent