CVS difference for ai05s/ai05-0177-1.txt
--- ai05s/ai05-0177-1.txt 2011/01/31 04:37:12 1.9
+++ ai05s/ai05-0177-1.txt 2011/02/04 07:04:48 1.10
@@ -1,7 +1,7 @@
-!standard 3.1(3/2) 11-01-03 AI05-0177-1/06
+!standard 3.1(3/2) 11-02-03 AI05-0177-1/07
!standard 3.11.1(1/1)
-!standard 6.1(20)
-!standard 6.1(30)
+!standard 6.1(20/2)
+!standard 6.1(30/2)
!standard 6.7(2/3)
!standard 6.7(3/2)
!standard 6.7(5/2)
@@ -94,13 +94,12 @@
expression_function_declaration that completes another declaration}, or a
renaming-as-body (see 8.5.4).
-
-Change 6.1(20):
+Change 6.1(20/2):
... A completion is not allowed for an abstract_subprogram_declaration{,} [or] a
null_procedure_declaration (see 6.7){, or an expression_function_declaration
(see 6.8)}.
-Modify 6.1(30):
+Modify 6.1(30/2):
A subprogram declared by an abstract_subprogram_declaration is abstract; a
subprogram declared by a subprogram_declaration is not. See 3.9.3, “Abstract
@@ -295,10 +294,6 @@
wording would be needed to ensure that they are properly included in "function"
and "subprogram" rules.
-We did "borrow" the parameterized expression name to mean the actual expression
-of an expression function. This simplifies some of the wording and reinforces
-the usage intent.
-
---
A goal for expression functions is that they represent a subset of the
@@ -310,7 +305,7 @@
represent a completion. This is not an important capability, but it increases
the consistency of the various kinds of subprogram declaration.
-Note that both null subprograms and expression functions are freeze when they
+Note that both null subprograms and expression functions freeze when they
are used as completions. There are a number of reasons for this:
(1) This is consistent with the behavior of explicit bodies. If the null procedure
@@ -366,18 +361,18 @@
---
-One could imagine these functions (when visible) to be used in static
+One could imagine allowing these functions (when visible) to be used in static
expressions if the inlined expression would be static. This would definitely
allow abstracting expressions that currently are written as a giant single
-expression because they need to be static. That's something you cannot do now. I
-didn't add this to proposal in order to keep the proposal simple.
+expression because they need to be static. That's something you cannot do now.
+We didn't add this to proposal in order to keep the proposal simple.
---
It has been suggested to allow expression functions as generic formal
subprogram defaults. This would increase the analogy with null procedures.
-I didn't include this for three reasons:
+We didn't include this for three reasons:
(1) The syntax would be very close to the existing default_name syntax. Adding
or removing parens would change the semantics substantially.
(2) This would probably require explicitly creating a body at the point of the
@@ -385,16 +380,16 @@
(3) We're not likely to make the analogy with null procedures complete (we would
need the next item as well), so there is going to be an inconsistency somewhere.
-Therefore, I stuck with the simpler proposal.
-
---
An additional idea would be to allow this as a primitive subprogram of an
interface. If we did that, we would get the benefit of the identity function
idea (see AI05-0140-1) without adding anything special specifically for that
case. The expression would have to be included in the 8.3 homograph matching
rules, probably by borrowing the rules for full conformance of expressions. That
-would be necessary to deal with the Steve Baird problem for diamond inheritance
-with interfaces (that was the primary reason that AI05-0140-1 was scuttled).
+would be necessary to deal with the problem of diamond inheritance with
+interfaces (that was the primary reason that AI05-0140-1 was scuttled) - otherwise
+it would be possible to inherit two expression functions with different expressions
+into a single type.
Including both this and the formal subprogram default would make this completely
similar to null procedures.
@@ -402,9 +397,240 @@
!example
(See wording.)
+
+!corrigendum 3.1(3/2)
+
+@drepl
+@xcode<@fa<basic_declaration ::=
+ type_declaration | subtype_declaration
+ | object_declaration | number_declaration
+ | subprogram_declaration | abstract_subprogram_declaration
+ | null_procedure_declaration | package_declaration
+ | renaming_declaration | exception_declaration
+ | generic_declaration | generic_instantiation>>
+@dby
+@xcode<@fa<basic_declaration ::=
+ type_declaration | subtype_declaration
+ | object_declaration | number_declaration
+ | subprogram_declaration | abstract_subprogram_declaration
+ | null_procedure_declaration | expression_function_declaration
+ | package_declaration | renaming_declaration
+ | exception_declaration | generic_declaration
+ | generic_instantiation>>
+
+
+!corrigendum 3.11.01(1)
+
+@drepl
+Declarations sometimes come in two parts. A declaration that requires a
+second part is said to @i<require completion>. The second part is called the
+@i<completion> of the declaration (and of the entity declared), and is
+either another declaration, a body, or a @fa<pragma>. A @i<body> is a @fa<body>,
+an @fa<entry_body>, or a renaming-as-body (see 8.5.4).
+@dby
+Declarations sometimes come in two parts. A declaration that requires a
+second part is said to @i<require completion>. The second part is called the
+@i<completion> of the declaration (and of the entity declared), and is
+either another declaration, a body, or a @fa<pragma>. A @i<body> is a @fa<body>,
+an @fa<entry_body>, a @fa<null_procedure_declaration> or an
+@fa<expression_function_declaration> that completes another declaration,
+or a renaming-as-body (see 8.5.4).
+
+!corrigendum 6.1(20/2)
+
+@drepl
+A @fa<subprogram_declaration> or a @fa<generic_subprogram_declaration> requires
+a completion: a body, a @fa<renaming_declaration> (see 8.5), or a @fa<pragma>
+Import (see B.1). A completion is not allowed for an
+@fa<abstract_subprogram_declaration> (see 3.9.3) or a
+@fa<null_procedure_declaration> (see 6.7).
+@dby
+A @fa<subprogram_declaration> or a @fa<generic_subprogram_declaration> requires
+a completion: a body, a @fa<renaming_declaration> (see 8.5), or a @fa<pragma>
+Import (see B.1). A completion is not allowed for an
+@fa<abstract_subprogram_declaration> (see 3.9.3), a
+@fa<null_procedure_declaration> (see 6.7), or an
+@fa<expression_function_declaration> (see 6.8).
+
+!corrigendum 6.1(30/2)
+
+@drepl
+A subprogram declared by an @fa<abstract_subprogram_declaration> is abstract;
+a subprogram declared by a @fa<subprogram_declaration> is not. See 3.9.3,
+"Abstract Types and Subprograms". Similarly, a procedure defined by a
+@fa<null_procedure_declaration> is a null procedure; a procedure declared by
+a @fa<subprogram_declaration> is not. See 6.7, "Null Procedures".
+@dby
+A subprogram declared by an @fa<abstract_subprogram_declaration> is abstract;
+a subprogram declared by a @fa<subprogram_declaration> is not. See 3.9.3,
+"Abstract Types and Subprograms". Similarly, a procedure defined by a
+@fa<null_procedure_declaration> is a null procedure; a procedure declared by
+a @fa<subprogram_declaration> is not. See 6.7, "Null Procedures".
+Finally, a function declared by an @fa<expression_function_declaration> is an
+expression function; a function declared by a @fa<subprogram_declaration> is not.
+See 6.8, "Expression Functions".
+
+!corrigendum 6.7(2/2)
+
+@dinsa
+@xcode<@fa<null_procedure_declaration ::=
+ [overriding_indicator]
+ procedure_specification >@b<@ft<is null>>;>>
+@dinst
+@s8<@i<Legality Rules>>
+
+If a @fa<null_procedure_declaration> is a completion, it shall be
+the completion of a @fa<subprogram_declaration> or @fa<generic_subprogram_declaration>.
+The profile of a @fa<null_procedure_declaration> that completes a declaration shall
+conform fully to that of the declaration.
+
+!corrigendum 6.7(3/2)
+
+@drepl
+A @fa<null_procedure_declaration> declares a @i<null procedure>.
+A completion is not allowed for a @fa<null_procedure_declaration>.
+@dby
+A @fa<null_procedure_declaration> declares a @i<null procedure>.
+A completion is not allowed for a @fa<null_procedure_declaration>, however
+a @fa<null_procedure_declaration> can complete a previous declaration.
+
+!corrigendum 6.7(5/2)
+
+@drepl
+The elaboration of a @fa<null_procedure_declaration> has no effect.
+@dby
+The elaboration of a @fa<null_procedure_declaration> has no other effect than to
+establish that the null procedure can be called without failing the
+Elaboration_Check.
+
+!corrigendum 6.8(0)
+
+@dinsc
+
+An @fa<expression_function_declaration> provides a shorthand to declare a function
+whose body consists of a single return statement.
+
+@s8<@i<Syntax>>
+
+@xcode<@fa<expression_function_declaration ::=
+ [overriding_indicator]
+ function_specification >@b<@ft<is>>@fa<
+ (expression)
+ [aspect_specification];>>
+
+@s8<@i<Name Resolution Rules>>
+
+The expected type for the @fa<expression> of an
+@fa<expression_function_declaration> is the result type (see 6.5) of the function.
+
+@s8<@i<Legality Rules>>
+
+If an @fa<expression_function_declaration> is a completion, it shall
+be the completion of a @fa<subprogram_declaration> or @fa<generic_subprogram_declaration>.
+The profile of an @fa<expression_function_declaration> that completes a declaration
+shall conform fully to that of the declaration.
+
+If the result subtype has one or more unconstrained access discriminants, the
+accessibility level of the anonymous access type of each access discriminant, as
+determined by the @fa<expression> of the expression function, shall not be statically deeper
+than that of the master that elaborated the @fa<expression_function_declaration>.
+
+@s8<@i<Static Semantics>>
+
+An @fa<expression_function_declaration> declares an @i<expression function>. A completion
+is not allowed for an @fa<expression_function_declaration>, however an
+@fa<expression_function_declaration> can complete a previous declaration.
+
+@s8<@i<Dynamic Semantics>>
+
+The execution of an expression function is invoked by a subprogram call. For the
+execution of a subprogram call on an expression function, the execution of the
+@fa<subprogram_body> is equivalent to a function body containing only a
+@fa<simple_return_statement> whose expression is that of the expression function.
+
+The elaboration of an @fa<expression_function_declaration> has no other effect than
+to establish that the expression function can be called without failing the
+Elaboration_Check.
+
+@s8<@i<Examples>>
+
+@xcode<@b<function> Is_Origin (P : @b<in> Point) @b<return> Boolean @b<is> -- @ft<@i<see 3.9>>
+ (P.X = 0.0 @b<and> P.Y = 0.0);>
+
+!corrigendum 7.5(2.8/2)
+
+@dinsa
+@xbullet<the @fa<expression> of a return statement (see 6.5)>
+@dinst
+@xbullet<the @fa<expression> of an @fa<expression_function_declaration> (see 6.8)>
+
+!corrignedum 8.3(18/2)
+
+@drepl
+@xinbull<For a @fa<package_declaration>, @fa<generic_package_declaration>,
+or @fa<subprogram_body>, the declaration is hidden from all visibility only
+until the reserved word @b<is> of the declaration;>
+@dby
+@xinbull<For a @fa<package_declaration>, @fa<generic_package_declaration>,
+@fa<subprogram_body>, or @fa<expression_function_declaration>, the declaration
+is hidden from all visibility only until the reserved word @b<is> of the
+declaration;>
+
+!corrigendum 8.3.1(3/2)
+
+@drepl
+If an @fa<abstract_subprogram_declaration>,
+@fa<null_procedure_declaration>,
+@fa<subprogram_body>, @fa<subprogram_body_stub>,
+@fa<subprogram_renaming_declaration>, @fa<generic_instantiation> of a
+subprogram, or
+@fa<subprogram_declaration> other than a protected subprogram
+has an @fa<overriding_indicator>, then:
+@dby
+If an @fa<abstract_subprogram_declaration>,
+@fa<null_procedure_declaration>, @fa<expression_function_declaration>,
+@fa<subprogram_body>, @fa<subprogram_body_stub>,
+@fa<subprogram_renaming_declaration>, @fa<generic_instantiation> of a
+subprogram, or
+@fa<subprogram_declaration> other than a protected subprogram
+has an @fa<overriding_indicator>, then:
+
+!corrignedum 13.14(8/1)
+
+@drepl
+A static expression causes freezing where it occurs. An object
+name or nonstatic expression causes freezing where it occurs, unless
+the name or expression is part of a @fa<default_expression>, a
+@fa<default_name>, or a per-object expression of a component's @fa<constraint>,
+in which case, the freezing occurs later as part of another construct.
+@dby
+A static expression causes freezing where it occurs. An object
+name or nonstatic expression causes freezing where it occurs, unless
+the name or expression is part of a @fa<default_expression>, a
+@fa<default_name>, the @fa<expression> of an expression function,
+or a per-object expression of a component's @fa<constraint>,
+in which case, the freezing occurs later as part of another construct.
---!corrigendum 6.8(0)
+!corrigendum 13.14(10)
+@dinsa
+@xbullet<At the place where an expression causes freezing, the type of the expression
+is frozen, unless the expression is an enumeration literal used as a @fa<discrete_choice>
+of the @fa<array_aggregate> of an @fa<enumeration_representation_clause>.>
+@dinss
+@xbullet<At the place where a function call causes freezing, the profile of the function is
+frozen. Furthermore, if a parameter of the call is defaulted, the
+@fa<default_expression> for that parameter causes freezing. If the function call is
+to an expression function, the @fa<expression> of the expression
+function causes freezing.>
+
+@xbullet<At the place where a @fa<generic_instantiation> causes freezing of a callable entity,
+the profile of that entity is frozen; if the callable entity is an expression
+function, the @fa<expression> of the expression function causes freezing.>
+
+@xbullet<At the place where a use of the Access or Unchecked_Access attribute whose
+@fa<prefix> denotes an expression function causes freezing, the @fa<expression> of the
+expression function causes freezing.>
!ACATS test
Questions? Ask the ACAA Technical Agent