Version 1.1 of ai12s/ai12-0147-1.txt

Unformatted version of ai12s/ai12-0147-1.txt version 1.1
Other versions for file ai12s/ai12-0147-1.txt

!standard 9.4(8/1)          15-01-21 AI05-0147-1/01
!class binding interpretation 15-01-21
!status work item 15-01-21
!status received 15-01-21
!priority Low
!difficulty Easy
!qualifier Omission
!subject Expression functions can be declared in a protected_body
Expression functions and null procedures can be declared in the body of a protected type.
Is it permissible to use an expression function as the completion of a protected function? (Yes.)
6.8(2/3) defines an expression_function_declaration as something separate from a subprogram_declaration, but 9.4(8/1) only allows subprogram_declaration, subprogram_body, entry_body, and aspect_clause.
(See Summary.)
Modify 9.4(8/1):
protected_operation_item ::= subprogram_declaration | subprogram_body
{ | null_procedure_declaration
| expression_function_declaration | entry_body | aspect_clause
It appears to be an oversight that expression functions are not allowed in a protected body. They are semantically the same as the full declaration of a function body with a single return statement, so there can be no significant implementation burden, and there seems to be no reason to not allow the shorthand in protected bodies.
Similarly, null procedures should be allowed in protected bodies. They are also semantically the same as a null body for a procedure, and again there is no reason to not allow the shorthand.
Note that this not only allows expression functions and null procedures to be completions, but also to declare body-only expression functions and null procedures. The language already allows that, and while a hidden null procedure doesn't seem useful, a hidden function can be used to encapsulate a complex barrier expression. There seems to be no reason to require a full body for such a function rather than allowing an expression function.
Note that we are not allowing expression functions or null procedures to be used in the specification of a protected type or object. These contexts do not currently allow any sort of body, and there may be implementation complications in allowing that. (We would need to change at least 9.4(5/1) to do so.)
[Editor's question: Should we allow that? It would make some sense, especially for protected types that implement some interface and thus have to create implementations for routines that they don't need to provide much functionality. It probably wouldn't be hard to support (worst case, the body could logically appear in the protected_body), but it doesn't seem that necessary, either -- the specification of a protected_type is a very restricted place as to what can be written, so I don't think people are going to be too worried about an apparent inconsistency with package specifications - you can't have types or objects in the visible part of a protected type, either (and types are a significant problem in practice.)]
Probably need to add expression functions and null procedures to the appropriate list of result types.
!ACATS test
An ACATS C-Test is needed to check that this is allowed. An ACATS B-Test that expression functions and null procedures are not allowed in the specifications of protected types also would be useful.

From: Randy Brukardt
Sent: Wednesday, January 21, 2015  2:53 PM

Simon Wright asked the following on comp.lang.ada:

Is it permissible to use an expression function as the completion of a
protected function? (GNAT thinks so).

ARM 6.1(30) distinguishes an expression_function_declaration from a

6.8(4) allows an expression_function_declaration to be a completion.

9.4(8) says a protected_operation_item can be, inter alia, a
subprogram_declaration or a subprogram body.

[Back to Randy]

I can't think of a good reason not to allow expression functions (and null
subprograms, too, to be consistent) in protected bodies. There's no absolute
requirement to allow either of them, as obviously both have an equivalent full
body, but it seems odd to not allow the shorthands in this context.
(*Especially* if GNAT allows them.)

So I think that expression_function_declaration and null_subprogram_declaration
are missing from syntax for protected_operation_item. When we made these
possible completions, we failed to notice that the list of allowed syntax for
protected operations needs to be changed.


From: Tucker Taft
Sent: Wednesday, January 21, 2015  2:59 PM

Works for me!  Uniformity seems like a good thing here.


From: Bob Duff
Sent: Wednesday, January 21, 2015  4:01 PM

Me too!


Questions? Ask the ACAA Technical Agent