Re: Extended return question

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Adam Beneschan <adam@irvine.com> writes:

> On Jul 10, 7:37 am, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> Dale Stanbrough <MrNoS...@bigpoop.net.au> writes:
>> > The purpose of an extended return is to create the values in-situ
>> > without copying.
>>
>> No, that's not correct.  Limited function results are built in place,
>> nonlimited ones are not.  It's got nothing to do with which sort of
>> return statement you use -- limited builds in place even when you
>> say "return <expression>;".
>
> Actually, the situation with limited types isn't totally clear,
> either.

It's pretty clear to me.  ;-)

I agree the RM wording is not crystal clear -- hence the AI you mention
below.

>...However, for limited types, there's no way Dale could test
> this using the sort of example he used above, since he used his
> Extended_Return_Function on the right-hand side of an assignment,
> which wouldn't be allowed for a function returning a limited type.

Right.

But if we're being really precise, we need to use standard Ada terms.
"Assignment" is (confusingly) not a shorthand for "assignment
statement", in Ada.  You mean "assignment statement" above.

And when I said "limited" in my previous message, I really meant
"immutably limited", as Randy pointed out.  A limited private type whose
full type is "range 1..10", or a generic formal limited private type
whose actual is "range 1..10" doesn't count.  We're talking about types
that are really limited, "deep down".

>...If
> he tried to use the function call as an initializer for some object X,
> and the function raised an exception and left, there's no way X could
> be examined to determine whether some of the components of X were set.

Right.  That's one of the cases where the compiler can safely use
build-in-place for nonlimited types.

> But in AI05-67, I did come up with an example where an extended return
> with a limited function result was left with a GOTO, and the function
> then did another extended return, and I had a question about whether
> the components set up by the first extended return (if not overwritten
> by the second) were required to show up in the result.  Your answer,
> Bob, was "no",...

Right.  For inherently limited types, the return object, and the object
being initialized are one and the same object.  But the object
being initialized doesn't exist until the return statement completes
successfully -- if it is left via goto, exit, or (more likely) an
exception, then a different return object may eventually be created,
which will _be_ the object being initialized.

>... and I think that if AI05-67 is adopted, the answer will
> still be "no", because this AI says that the function result object
> does not "morph" into the created object until the return is
> completed.  The upshot of this AI is, I think, that (1) the object
> being worked on for an extended return is *not* an "alias" for the
                         ^^^^^^^^^^^^^^^
Again, the return syntax is irrelevant!

> object being created, even for a limited type,...

For an immutably limited type, the return object is an alias for object
that _will_ be created, if we get that far.

>.. and (2) although
> limited types aren't supposed to be copied, this is true only in an
> Ada semantic sense, and implementations are allowed to do any block-
> copies they wish as long as they get the Ada semantics right.

Yes, of course -- if an implemention has garbage collection, it can copy
anything it likes, including tasks, so long as it patches up all the
pointers properly, so the copying is semantically invisible.

E.g. if you have a record with a Self component that points to the
record, it had better still point to itself after returning from the
function.  The easiest way to implement that is to make sure that the
address of the return object is the same as the address of the
newly-created object at the call site (which is exactly what GNAT
does).

- Bob