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

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

!standard 9.4(8/1)          15-01-28 AI12-0147-1/02
!class binding interpretation 15-01-21
!status Corrigendum 2015 15-01-28
!status WG9 Approved 15-06-26
!status ARG Approved 10-0-0 15-01-28
!status work item 15-01-21
!status received 15-01-21
!priority Low
!difficulty Easy
!qualifier Omission
!subject Expression functions and null procedures can be declared in a protected_body
!summary
Expression functions and null procedures can be declared in the body of a protected type.
!question
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.
!recommendation
(See Summary.)
!wording
Modify 9.4(8/1):
protected_operation_item ::= subprogram_declaration | subprogram_body
{ | null_procedure_declaration
| expression_function_declaration} | entry_body | aspect_clause
!discussion
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 for subprogram declarations, 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. That seems OK, as the specification of a protected_type is a very restricted place as to what can be written, so the apparent inconsistency with package specifications is insignificant - you can't have types (anywhere) or objects (in the visible part) of a protected_type, either.
!corrigendum 9.4(8/1)
Replace the paragraph:
protected_operation_item ::= subprogram_declaration | subprogram_body | entry_body | aspect_clause
by:
protected_operation_item ::= subprogram_declaration | subprogram_body | null_procedure_declaration | expression_function_declaration | entry_body | aspect_clause
!ASIS
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.
!appendix

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

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!

****************************************************************

From: Simon Wright
Sent: Thursday, January 22, 2015  5:51 AM

> So I think that expression_function_declaration and 
> null_subprogram_declaration are missing from syntax for 
> protected_operation_item.

null_procedure_declaration

****************************************************************

From: Simon Wright
Sent: Thursday, January 22, 2015  6:04 AM

but, fyi, GNAT says "buttons.adb:92:07: protected operation cannot be a null
procedure”.

****************************************************************

From: Randy Brukardt
Sent: Thursday, January 22, 2015  6:28 PM

So GNAT is inconsistently consistent. :-) It makes no sense to treat
expression functions and null procedures differently here, especially as a
null procedure could be useful in completing a protected operation inherited
from an interface. Either allow no shorthands, or all shorthands.

****************************************************************

Questions? Ask the ACAA Technical Agent