!standard 6.5(2.1/2) 07-05-17 AI05-0015-1/04 !standard 3.3(10/2) !standard 3.3(21) !standard 6.5(5/2) !standard 6.5(5.7/2) !class binding interpretation 06-05-25 !status Amendment 201Z 08-11-26 !status WG9 Approved 07-06-29 !status ARG Approved 11-1-0 06-11-18 !status work item 06-05-25 !status received 06-05-25 !priority High !difficulty Easy !qualifier Omission !subject Constant return objects !summary The return object declared in an extended_return_statement may be declared "constant". !question 6.5(2.1/2) says: extended_return_statement ::= return defining_identifier : [aliased] return_subtype_indication [:= expression] [do handled_sequence_of_statements end return]; Is it intended that the reserved word "constant" should be allowed? (Yes.) !recommendation The return object declared in an extended_return_statement may be declared "constant". !wording Add the optional "constant" reserved word to 6.5(2.1/2): extended_return_statement ::= return defining_identifier : [aliased] [constant] return_subtype_indication [:= expression] [do handled_sequence_of_statements end return]; Replace 3.3(10/2) with: * the return object of a function; Replace 3.3(21) with: * the return object declared by an extended_return_statement with the reserved word constant; * the object denoted by a function_call or aggregate; Add to 6.5(5/2) An extended_return_statement with the reserved word constant shall include an expression. Add to 6.5(5.7/2) An extended_return_statement with the reserved word constant is a full constant declaration for the return object. !discussion The omission of "constant" from the syntax of extended_return_statement was an oversight. Clearly, examples such as the following should be allowed: function F (...) return Limited_Type is begin return Result: constant -- Illegal! Limited_Type := (Foo => ..., Bar => ...) do Print_Trace("Created object " & Image(Result)); pragma Assert(Some_Property(Result)); end return; end F; function G (...) return Limited_Type is begin return Result : constant Limited_Type -- Illegal as language stands! := Func(Some_Object) do Clean_Up(Some_Object); end return; end G; Along with the added the keyword constant to the syntax of extended return statements, the definition of a constant object needs to be extended to include these. We also corrected 3.3(10/2) so it clearly covers the return object of a function both inside and after a function call. !corrigendum 3.3(10/2) @drepl @xbullet (or the equivalent operator invocation @mdash see 6.6);> @dby @xbullet !corrigendum 3.3(21) @drepl @xbullet or an @fa;> @dby @xbullet with the reserved word @b;> @xbullet or @fa;> !corrigendum 6.5(2.1/2) @drepl @xcode<@fa@ft<@b>@fa< defining_identifier : [>@ft<@b>@fa<] return_subtype_indication [:= expression] [>@ft<@b>@fa< handled_sequence_of_statements >@ft<@b>@fa<];>> @dby @xcode<@fa@ft<@b>@fa< defining_identifier : [>@ft<@b>@fa<] [>@ft<@b>@fa<] return_subtype_indication [:= expression] [>@ft<@b>@fa< handled_sequence_of_statements >@ft<@b>@fa<];>> !corrigendum 6.5(5/2) @drepl A function body shall contain at least one return statement that applies to the function body, unless the function contains @fas. A @fa shall include an @fa if and only if it applies to a function body. An @fa shall apply to a function body. @dby A function body shall contain at least one return statement that applies to the function body, unless the function contains @fas. A @fa shall include an @fa if and only if it applies to a function body. An @fa shall apply to a function body. An @fa with the reserved word @b shall include an @fa. !corrigendum 6.5(5.7/2) @drepl Within an @fa, the @i is declared with the given @fa, with the nominal subtype defined by the @fa. @dby Within an @fa, the @i is declared with the given @fa, with the nominal subtype defined by the @fa. An @fa with the reserved word @b is a full constant declaration for the return object. !ACATS test An ACATS C-Test should be created to test that "constant" is allowed. !appendix From: Robert A. Duff Date: Saturday, May 13, 2006 12:16 PM The syntax rules do not allow this: function F (...) return Limited_Type is begin return Result: constant -- Illegal! Limited_Type := (Foo => ..., Bar => ...) do Print_Trace("Created object " & Image(Result)); pragma Assert(Some_Property(Result)); end return; end F; It seems like the above is a pretty reasonable thing to do, and it seems that Result should be marked "constant", since it is, in fact, constant. Is there any particular reason why "constant" is illegal here? This also makes me wonder why we need a declared name for the return object in order to have a "do" part. The following also seems pretty reasonable: function G (...) return Limited_Type is begin return Func(Some_Object) do -- Illegal! Clean_Up(Some_Object); end return; end G; I'm presuming Func depends on the un-cleaned-up state of Some_Object, so: Clean_Up(Some_Object); return Func(Some_Object); won't work. Note that neither of the above examples can be written without using the "do" notation of extended_return_statement. E.g., we can't say: function G (...) return Limited_Type is Result: constant Limited_Type := Func(Some_Object); begin Clean_Up(Some_Object); return Result; -- Illegal! end G; because the type is limited. Even if it were nonlimited, the extended_return_statement will be more efficient if the object is large (unless the compiler is more clever than I expect). Gary Dismukes asked me why didn't I mention this some years ago. I said I wasn't paying enough attention, but even if I had been, I probably would not have realized the problem. The reason I realized it now is that I wrote something like the above F while testing GNAT's implementation of AI-318, and GNAT warned something like: "Result is not modified; could be declared constant" which would be more accurate if it said: "Result is not modified; SHOULD be declared constant, but can't be" ;-) The G example isn't so bad, but for the F example, it really seems like a wart to me to disallow "constant". **************************************************************** From: Tucker Taft Date: Saturday, May 13, 2006 7:40 PM I can't think of any reason we shouldn't allow "constant." So I agree it is reasonable to make this syntax change. It seems an oversight that we didn't allow it originally. **************************************************************** From: Robert Dewar Date: Sunday, May 14, 2006 2:26 AM I agree, let's just consider this to be a typographical error. After all the precedent is there, in Ada 83, we decided that the failure to insist on components being independent was a typographical error in the printers proof (of course that was a huge mistake, but in this case I don't think we need to worry that we are introducing a big change at the last minute :-) **************************************************************** From: Randy Brukardt Date: Sunday, May 14, 2006 3:50 PM I'm not quite sure what you mean. If you mean to treat the change as an omission in our next Corrigendum (or whatever the form the next formal correction takes), I think that's fine. We've done that with things that are on the cusp of being extensions all the time. (Which means that the AI will take the form of a Binding Interpretation, and we all can follow it right away.) But if you mean to actually change the Amendment as it goes through, I think we need to stick to real typos; otherwise, we're putting the dual copyright status of the documents at risk. And I think we all agree that free availability is important here. I'm sure you're hard at work on a Binding Interpretation AI for this topic (so it can be considered in (O)Porto). ;-) **************************************************************** From: Robert Dewar Date: Sunday, May 14, 2006 4:58 PM > But if you mean to actually change the Amendment as it goes through, I think > we need to stick to real typos; otherwise, we're putting the dual copyright > status of the documents at risk. And I think we all agree that free > availability is important here. I am saying it's a real typo "oops, we left out CONSTANT here in the syntax, anyone can see that it should be there". Meanwhile, I would suggest NOT building any test that ensures it is not allowed, and everyone can go ahead and implement it without being intefered with :-) **************************************************************** From: Pascal Leroy Date: Monday, May 15, 2006 1:43 AM I agree with Randy. Changing the Amendment that went to SC22 is not an option, if only because of the copyright issue, but also because it could cause us to get negative votes. On the other hand, a BI saying "you know, we really meant constant here" sounds like a fine idea. (And the ACATS should not test that "constant" is rejected, of course.) **************************************************************** From: Robert Dewar Date: Monday, May 15, 2006 1:53 AM Sounds fine, no one really cares about what the RM says, it is the ACATS test that arbitrate the language in practice :-) :-) So a concious decision not to test a requirement in the RM is tantamount to eliminating the requirement in practice. We will go ahead and allow constant in our implementation I think ... **************************************************************** From: Pascal Leroy Date: Monday, May 15, 2006 2:51 AM > Sounds fine, no one really cares about what the RM says, it > is the ACATS test that arbitrate the language in practice :-) :-) Given that there is no ACATS for Ada 2005 at this point, the logical conclusion from your reasoning is that nobody cares about Ada 2005 :-> > We will go ahead and allow constant in our implementation I think ... It's your decision of course, but if I were you I would wait a bit until the ARG has taken a look at this issue. The idea sounds reasonable, but there might be dragons that would kill it. That has happened before. You only know once an AI has been written and discussed. **************************************************************** From: Robert A. Duff Date: Monday, May 15, 2006 7:44 AM > But if you mean to actually change the Amendment as it goes through, I think > we need to stick to real typos;... I agree. >... otherwise, we're putting the dual copyright > status of the documents at risk. And I think we all agree that free > availability is important here. What is the "dual copyright" issue, and how does it affect the "free availability" issue? I agree that we all agree that free availability is important here. ;-) > I'm sure you're hard at work on a Binding Interpretation AI for this topic > (so it can be considered in (O)Porto). ;-) I'd be happy to write something up at some point. But I am going to do something about this issue in the next day or two, one way or the other. I must either implement "constant" in the GNAT parser, or else turn off the slightly embarrassing warning that says you should use "constant" when you're not allowed to. I suspect both are trivial to implement. I would like to see a Binding Interpretation at some point. (Relying on the "wink wink, we won't test it" idea really rubs me the wrong way.) But perhaps ARG should wait until the ink is dry on the official ISO Standard before we start issuing Binding Interpretations... **************************************************************** From: Robert Dewar Date: Monday, May 15, 2006 8:10 AM >> Sounds fine, no one really cares about what the RM says, it >> is the ACATS test that arbitrate the language in practice :-) :-) > > Given that there is no ACATS for Ada 2005 at this point, the logical > conclusion from your reasoning is that nobody cares about Ada 2005 :-> Notice the interesting little switch here :-) I note that no one really cares about the RM, and Pascal turns that into not caring about the language. In practice, as has always been the case, the more important thing is what the implementations allow, not what the RM says. For example, for quite some time, RM83 did not permit static subtypes of e.g. Integer to be declared. But of course all implementations allowed them, so no one cared about the RM, and the subsequent fixing of the RM was an excercise of interest to language lawyers only :-) Well of course the static subtypes are a bit of an extreme case! In the case of Ada 95, System.Bit_Order was accidentally made non-static, and AdaCore foolishly followed the RM, which was too bad, since no one else did, and it just caused our customers switching from other compilers trouble :-) > >> We will go ahead and allow constant in our implementation I think ... > > It's your decision of course, but if I were you I would wait a bit until > the ARG has taken a look at this issue. The idea sounds reasonable, but > there might be dragons that would kill it. That has happened before. You > only know once an AI has been written and discussed. In this case, I think it is obvious that there are no dragons. We are just talking about an obvious syntax fix. In fact for GNAT it is less trouble to remove this syntax glitch, than to fiddle around suppressing the (legitimate) warning :-) I would rather people use the constant from the start, rather than waiting till later when it will cause everyone an annoyance by generating warnings where none were given before. **************************************************************** From: Robert A. Duff Date: Thursday, May 25, 2006 1:41 PM I have included a draft AI below [this is version /01 of the AI - ED]. Randy, please let me know what AI number you assign to this. Pascal, you might want to put this on the agenda for the next meeting. ****************************************************************