Re: Will "renames" increase program size?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 16 Jun 2011 08:40:41 -0700 (PDT), Adam Beneschan wrote:

> On Jun 16, 1:59�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>
>>> That's not correct. A renaming does not copy nor somehow create new
>>> entities, it only creates new names for the same thing. Since
>>> visibility is via names, you arrive at unresolvability issues.
>>
>> No. First, sometimes it certainly copies, e.g. when the function's result
>> is renamed, the result (temporary object) is copied. The compiler might
>> optimize the temporary object away, or even mandated to do so for limited
>> results, but *semantically* it is a copy.
> 
> I don't think that's right.  The test would be:
> 
>    type T1 is new Ada.Finalization.Controlled with record
>       F1 : Integer;
>    end record;
>    overriding
>    procedure Adjust (Obj : in out T1);
> 
>    function Func (N : Integer) return T1 is
>    begin
>       return Ret : T1 do
>          T1.F1 := N;
>       end return;
>    end Func;
> 
>    procedure Proc is
>       R : T1 renames Func(3);
>    begin
>       ...
>    end Proc;
> 
> In this example, I believe that the renaming declaration cannot
> legally cause Adjust to be called.

I.e. the optimization is mandated for all tagged types in presence of
return statement. Nevertheless Func creates a new object, which is then
renamed.

> In the renaming case, as I read the RM, the extended return creates a
> return object, the function call denotes a constant view of the return
> object, and the renaming denotes a new view of the return object.
> There's no copying or assignment involved.  (Of course, the compiler
> could generate some sort of block-copy to implement this, but I think
> we're talking about Ada semantics.

Semantically returning result of a function is always copying because the
object being returned changes the scope. You have a fully constructed
object #1 within the scope of the return statement. You have a fully
constructed object #2 in the scope of the function call. These are
semantically two different objects because scopes are different. That both
objects might share the same physical memory and therefore no physical
copying is needed, looks like an implementation detail to me.

Of course an alternative point of view is also possible: the object is
rather a closure which floats from one scope to another remaining "same".
But I think that this logical model is unnatural to Ada, and does not work
with by-value types anyway.

I think this could be analogous to inlined bodies. A call is semantically a
call even though nothing is actually called.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de