Question about finalization of local object returned from the function

Question about finalization of local object returned from the function

[darkestkhan]

Given a function returning controlled type:

function Bar return T is
  Foo : T;
begin
  ...
  return Foo;
end Bar;

would Foo be finalized upon end of the function?

As far as I can understand from the standard - yes, Foo would get finalized. Also if Foo was just a normal record type with controlled components those components would be finalized as well.

But I am not fully confident that my understanding of this is correct...

Thanks,
darkestkhan

Re: Question about finalization of local object returned from the function

[Brad Moore]

On Wednesday, August 28, 2019 at 4:36:38 PM UTC-6, darkestkhan wrote:
> Given a function returning controlled type:
> 
> function Bar return T is
>   Foo : T;
> begin
>   ...
>   return Foo;
> end Bar;
> 
> would Foo be finalized upon end of the function?
> 
> As far as I can understand from the standard - yes, Foo would get finalized. Also if Foo was just a normal record type with controlled components those components would be finalized as well.
> 
> But I am not fully confident that my understanding of this is correct...
> 
> Thanks,
> darkestkhan

Yes Foo is finalized upon end of the function, but not before copying the
object to a temporary result object which is returned to the caller. The temporary is finalized also after being assigned to the result object.
In other words, the expected result is returned to the caller, and the Foo object on the stack is also properly finalized.

Note if the object is a Limited_Controlled type, and the extended return syntax is used, then the result object is said to be "built-in-place" directly into the result variable. The object is not finalized until the result variable is finalized. This allows a function returning a limited type to, for example, initialize a variable of a limited type.

Brad

Re: Question about finalization of local object returned from the function

[Stephen Leake]

On Wednesday, August 28, 2019 at 6:45:16 PM UTC-7, Brad Moore wrote:
> On Wednesday, August 28, 2019 at 4:36:38 PM UTC-6, darkestkhan wrote:
> > Given a function returning controlled type:
> > 
> > function Bar return T is
> >   Foo : T;
> > begin
> >   ...
> >   return Foo;
> > end Bar;
> > 
> > would Foo be finalized upon end of the function?
> > 
> 
> Yes Foo is finalized upon end of the function, but not before copying the
> object to a temporary result object which is returned to the caller. The temporary is finalized also after being assigned to the result object.
> In other words, the expected result is returned to the caller, and the Foo object on the stack is also properly finalized.
> 

However, the compiler is free to optimize away any of these steps, as long as the net effect is preserved.

To expand on Brad's comment about the extended return statement, consider:

function Bar return T is
begin
   return Foo : T do
      ...
   end return;
end Bar;

then 'Foo' is actually the object that the client has declared/allocated. For example:

declare
   A : T := Bar;
begin
...

"Foo" is actually "A", so no temporary objects are required. 

I don't think Limited_Controlled is required for this to happen; ARM 6.5 (24/3) mentions "built in place", but not Limited_Controlled. Also ARM 7.6 (17.1/3) gives the conditions where "built in place" is required.

-- Stephe

Re: Question about finalization of local object returned from the function

[darkestkhan]

On Sunday, September 1, 2019 at 6:34:07 PM UTC, Stephen Leake wrote:
> On Wednesday, August 28, 2019 at 6:45:16 PM UTC-7, Brad Moore wrote:
> > On Wednesday, August 28, 2019 at 4:36:38 PM UTC-6, darkestkhan wrote:
> > > Given a function returning controlled type:
> > > 
> > > function Bar return T is
> > >   Foo : T;
> > > begin
> > >   ...
> > >   return Foo;
> > > end Bar;
> > > 
> > > would Foo be finalized upon end of the function?
> > > 
> > 
> > Yes Foo is finalized upon end of the function, but not before copying the
> > object to a temporary result object which is returned to the caller. The temporary is finalized also after being assigned to the result object.
> > In other words, the expected result is returned to the caller, and the Foo object on the stack is also properly finalized.
> > 
> 
> However, the compiler is free to optimize away any of these steps, as long as the net effect is preserved.
> 
> To expand on Brad's comment about the extended return statement, consider:
> 
> function Bar return T is
> begin
>    return Foo : T do
>       ...
>    end return;
> end Bar;
> 
> then 'Foo' is actually the object that the client has declared/allocated. For example:
> 
> declare
>    A : T := Bar;
> begin
> ...
> 
> "Foo" is actually "A", so no temporary objects are required. 
> 
> I don't think Limited_Controlled is required for this to happen; ARM 6.5 (24/3) mentions "built in place", but not Limited_Controlled. Also ARM 7.6 (17.1/3) gives the conditions where "built in place" is required.
> 
> -- Stephe

That is correct - "built in place" semantics has more uses than just
for limited types, although it does make working with limited types
far simpler. Not to mention that extended return has some extra uses
as well - I use it now and then for doing cleanup before return, i.e.:

function Baz (...) return T is
  ...
begin
  ...
  return Result : constant T  := ...  do
    ... -- and some cleanup code (free temporary variables / close files)
  end return;
end Baz;

Instead of declaring result in declare block and then cleaning up and
returning it. I just find this way to be more... descriptive, of what
is actually happening. Admittedly cleanup at the end of *function* is
very infrequent.

Thanks for confirming my understanding of this situation.

-- darkestkhan

Re: Question about finalization of local object returned from the function

[Jeffrey R. Carter]

On 9/2/19 12:12 AM, darkestkhan wrote:
> On Sunday, September 1, 2019 at 6:34:07 PM UTC, Stephen Leake wrote:
>> On Wednesday, August 28, 2019 at 6:45:16 PM UTC-7, Brad Moore wrote:
>>> On Wednesday, August 28, 2019 at 4:36:38 PM UTC-6, darkestkhan wrote:
>>>> Given a function returning controlled type:
>>>>
>>>> function Bar return T is
>>>>    Foo : T;
>>>> begin
>>>>    ...
>>>>    return Foo;
>>>> end Bar;
>>>>
>>>> would Foo be finalized upon end of the function?
>>>>
>>>
>>> Yes Foo is finalized upon end of the function, but not before copying the
>>> object to a temporary result object which is returned to the caller. The temporary is finalized also after being assigned to the result object.
>>> In other words, the expected result is returned to the caller, and the Foo object on the stack is also properly finalized.
>>>
>>
>> However, the compiler is free to optimize away any of these steps, as long as the net effect is preserved.
>>
>> To expand on Brad's comment about the extended return statement, consider:
>>
>> function Bar return T is
>> begin
>>     return Foo : T do
>>        ...
>>     end return;
>> end Bar;
>>
>> then 'Foo' is actually the object that the client has declared/allocated. For example:
>>
>> declare
>>     A : T := Bar;
>> begin
>> ...
>>
>> "Foo" is actually "A", so no temporary objects are required.
>>
>> I don't think Limited_Controlled is required for this to happen; ARM 6.5 (24/3) mentions "built in place", but not Limited_Controlled. Also ARM 7.6 (17.1/3) gives the conditions where "built in place" is required.
>>
>> -- Stephe
> 
> That is correct - "built in place" semantics has more uses than just
> for limited types, although it does make working with limited types
> far simpler.

Maybe I'm misreading this, but it sounds to me as if those posting after Moore 
are saying that the language requires build in place when an extended return 
statement is used. It doesn't. The language only requires that "immutably 
limited" types and aggregates of controlled types be built in place. Note that 
aggregates of non-limited controlled types are returned without using extended 
return, but still require build in place.

Other types may be returned through assignment, as Moore described, even if an 
extended return is used. A compiler is free to do build in place for other 
types, but not required to.

-- 
Jeff Carter
"The competent programmer is fully aware
of the limited size of his own skull."
Edsger Dijkstra
159