Re: another way to shoot yourself in the foot?

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

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Of course you're passing a reference, since limited types are always
> passed by reference (since Ada 95). But I don't think that the object
> had to exist before the call to F:

Yes, you're right.  I was wrong to say it had to exist before.
To give the precise answer, I'd have to talk about "accessibility
levels".  Basically, in Ada 95, F returns an implicit reference
to something "outside of" F -- outside in the sense of having
a longer potential lifetime.

In Ada 2005, it's just the opposite -- F returns something created by F.

> procedure Task_Return_Test is
>    package Wrap is
>       task type T;
>
>       function F return T;
>    end Wrap;
>
>    package body Wrap is
>       type T_Ptr is access T;
>
>       function F return T is
>          R : T_Ptr := new T;
>       begin -- F
>          return R.all;
>       end F;
>
>       task body T is
>          -- null;
>       begin -- T
>          null;
>       end T;
>    end Wrap;
>
>    procedure P (V : in Wrap.T) is
>       -- null;
>    begin -- P
>       null;
>    end P;
> begin -- Task_Return_Test
>    P (V => Wrap.F);
> end Task_Return_Test;
>
> This is valid Ada 95, according to a compiler.

It is also valid Ada 95, according to the Ada 95 Reference Manual.  ;-)
It is illegal in Ada 2005.

I claim that it would be clearer (in Ada 95) for F to return an
access-to-T, since that's what is really going on.  And in Ada 2005,
you have to do it that way.

>> Well, there are only two ways a function call can be used: to initialize
>> a new object, or to update an existing object (i.e. on the right-hand
>> side of an assignment statement).  But don't forget there are a dozen or
>> so different ways of creating new objects (components, parameters,
>> parent parts of aggregates, etc).  All of these are allowed for
>> build-in-place function calls.  The only thing that's not allowed is the
>> assignment statement.
>> You can still say:
>>     P(F(...));
>> where F returns a limited type.  Yes, there's a new object being
>> created
>> (the formal parameter of P), and F is being used to initialize that
>> object (in place!).  In Ada 2005, functions always return newly-created
>> objects, which I think is appropriate.
>
> I learned that functions return objects, and in this case the object is
> the actual parameter to P, not the formal parameter. The object is
> anonymous.

No, that's not the right way to think about it (for limited types!).
The whole point of build-in-place is that the object created inside the
function at the "return", and the function result, and the actual
parameter of P, and the formal parameter of P -- are all one and the
same object!

If F said "return G(...);" and G said "return H(...);" we've got a whole
bunch of objects that are one and the same object, in the end.

As somebody mentioned, there's an AI that tries to clarify the wording
on this point.

>...Maybe that rule's changed for limited parameters in current
> Ada. But I take your point that F can be regarded as always building in
> place, wherever that place may be.

OK.

>>     if F(...).Flag then ...
>> The last one is pretty silly -- it creates a new limited object,
>> grabs a boolean flag out of it, and then throws the whole thing
>> away.
>
> It's also an example in which the object that F builds in is clearly
> anonymous, unlike the parameter of P above.

Right, at the call site, it's anonymous.  It might have a name inside F
(if F said "return Result : ...") or be anonymous inside F (if F said
"return <expression>"), but either way, it's one object.

- Bob