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

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

!standard 6.5(3/2)          15-10-05 AI05-0173-1/01
!standard 6.5(5/3)
!class binding interpretation 15-10-05
!status work item 15-10-05
!status received 15-08-24
!priority Low
!difficulty Easy
!qualifier Omission
!subject Expression of an extended return statement
!summary
The expression of an extended return statement is that of the extended_return_object_declaration.
!question
7.5(2.8/2) says:
the expression of a return statement (see 6.5)
This was intended to cover both simple and extended return statements, and did in Ada 2005.
However, in Ada 2012, we separated the syntax for extended_return_object_declaration to fix some other wording problem. That means that the syntax for an extended_return_statement no longer (directly) contains any expression. (Of course, it indirectly contains many expressions, but it's hard to figure why the expression in the return object is better than the ones in the statements contained in the sequence_of_statements.)
This wording or a variation is used in many places in the RM, especially (but not exclusively) in 6.5. Should we fix this definition? (Yes.)
!recommendation
(See Summary.)
!wording
Modify 6.5(3/2):
The result subtype of a function is the subtype denoted by the subtype_mark, or defined by the access_definition, after the reserved word return in the profile of the function. The expected type for the expression, if any, of a simple_return_statement is the result type of the corresponding function. The expected type for the expression of an {extended_return_object_declaration}[extended_return_statement] is that of the return_subtype_indication.
Modify 6.5(5/3):
A function body shall contain at least one return statement that applies to the function body, unless the function contains code_statements. A simple_return_statement shall include an expression if and only if it applies to a function body. An extended_return_statement shall apply to a function body. An {extended_return_object_declaration}[extended_return_statement] with the reserved word constant shall include an expression.
{The *<syntax-font>expression</syntax-font> of an <syntax-font>extended_return_statement</syntax-font>* is the <syntax-font>expression</syntax-font> of the <syntax-font>extended_return_object_declaration</syntax-font> of the <syntax-font>extended_return_statement</syntax-font>.}
!discussion
This happened when the grammar was changed to split xtended_Return_Object_Declaration out of Extended_Return_Statement. No one noticed the extensive wording discussing the expression (syntax font) of an extended_return_statement.
Neither of the two places that were changed need any reference to the extended return statement, and as they both precede the new definition, we changed them rather than introducing a forward reference.
!ASIS
No ASIS effect.
!ACATS test
Separate tests should not be needed.
!appendix

From: Randy Brukardt
Sent: Monday, August 24, 2015 10:09 PM

Here's a bug we introduced that I doubt anyone would get wrong unless they were
trying to be pedantic. I'm writing about it just to put it on the record so that
it is recorded somewhere.

7.5(2.8/2) says:

the expression of a return statement (see 6.5)

This was intended to cover both simple and extended return statements, and did
in Ada 2005.

However, in Ada 2012, we separated the syntax for
extended_return_object_declaration to fix some other wording problem. That means
that the syntax for an extended_return_statement no longer (directly) contains
any expression. (Of course, it indirectly contains many expressions, but it's
hard to figure why the expression in the return object is better than the ones
in the statements contained in the sequence_of_statements.)

To be pedantic, we probably should replace that text with:

* the expression of a simple_return_statement or extended_return_declaration

I note, however, that the same issue pops up multiple times in the wording of
6.5. For instance, 6.5(3/2) says in part:

The expected type for the expression of an extended_return_statement is that of
the return_subtype_indication.

But an extended_return_statement has neither an expression or a
return_subtype_indication.

Another such place is 6.5(5/3), which says in part:

An extended_return_statement with the reserved word constant shall include an
expression.

With the same objection as above. I stopped looking at this point. (Even so, I
saw that 6.5(5.7/3) and 6.5(5.8/3) appear also to have this issue.)

If we were going to fix this, probably we'd want to defined somewhere that the
expression of an extended_return_object_declaration is considered to be the
expression of an extended_return_statement, 'cause searching the RM for this
issue probably will turn up more wording that is affected. (We'd still need to
change 6.5(3/2), I think, as the resolution shouldn't mention the extended
return statement at all; it's not really relevant as nothing about it has any
effect on resolution.)

As such (and considering I think the majority of readers will understand what we
meant), I think this is best placed in the "bugs that we're not going to fix"
AI. Else, we could put it into a group AI of wording changes that don't intend
to change semantics. (This would be the first such issue for this cycle, but I'm
certain there will be more.)

Thoughts?

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

From: Tucker Taft
Sent: Tuesday, August 25, 2015  12:17 PM

...
> To be pedantic, we probably should replace that text with:
>
> * the expression of a simple_return_statement or
> extended_return_declaration

Isn't it "extended_return_object_declaration"?

...

> Thoughts?

I would definitely agree that we should define the "expression of an
extended_return_statement" to be "the <syntax-font>expression</syntax-font> of
the extended_return_object_declaration of the extended_return_statement" if we
decide to do anything.  I could also agree with a DNF decision (do not fix).

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

Questions? Ask the ACAA Technical Agent