Version 1.6 of ai05s/ai05-0015-1.txt

• the return object created as the result of evaluating a function_call (or the equivalent operator invocation @mdash see 6.6);

• the return object of a function;

• the result of evaluating a function_call or an aggregate;

• the return object declared by an extended_return_statement with the reserved word constant;

• the object denoted by a function_call or aggregate;

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.

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