Re: Initialization and Finalization of limited object "returned" by a function

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

Unless someone know a reason for an opposite interpretation, after
I've check the ARM, it seems indeed, things should be like I was
expecting.

[ARM 7.5(8.1/2)]
> For an aggregate of a limited type used to initialize an object as
> allowed above, the implementation shall not create a separate
> anonymous object for the aggregate. For a function_call of a type
> with a part that is of a task, protected, or explicitly limited
> record type that is used to initialize an object as allowed above,
> the implementation shall not create a separate return object (see
> 6.5) for the function_call. The aggregate or function_call shall be
> constructed directly in the new object.

[ARM 7.5(8.a/2)]
> Discussion: For a function_call, we only require
> build-in-place{build-in-place [partial]} for a limited type that
> would have been a return-by-reference type in Ada 95. We do this
> because we want to minimize disruption to Ada 95 implementations and
> users.

[ARM 7.5(9/2)]
> While it is allowed to write initializations of limited objects,
> such initializations never copy a limited object. The source of such
> an assignment operation must be an aggregate or function_call, and
> such aggregates and function_calls must be built directly in the
> target object. The following are consequences of the rules for
> limited types:

[ARM 7.5(9.a/2)]
> To be honest: This isn't quite true if the type can become
> nonlimited (see below); function_calls only are required to be
> build-in-place for “really” limited types.

[ARM 7.5(9.a/2)]
> As illustrated in 7.3.1, an untagged limited type can become
> nonlimited under certain circumstances.

[ARM 7.3.1(5/1)]
> For example, an array type whose component type is limited private
> becomes nonlimited if the full view of the component type is
> nonlimited and visible at some later place immediately within the
> declarative region in which the array type is declared. within the
> immediate scope of the array type. In such a case, the predefined
> "=" operator is implicitly declared at that place, and assignment is
> allowed after that place.

The latter, which would be the only one kind of exception, as stated
by [ARM 7.5(9.a/2)], does not apply in the example of the Test
program.

So I'm suspecting an error here : the object should indeed not be
Finalized when New_A or New_B terminates, as it do in Test.

All view are limited : public and private view. So no where a limited
view becomes a nonlimited view. Use of extended return statement is
made in all place. Although Tested_Interface is initialized via an
invocation of New_Instance, no Finalization occurs (as the spy shows)
when its scope terminates. Its initialized where it is expected to be
(in New_A and New_B), but it is Finalized at the wrong place, just
like if it was returned by copy.

Protected, and Task are indeed to be Initialized/Finalized the way I
was expecting :

[ARM 7.6(9.1-9.5)]
> 9.1/2 A type is said to need finalization if:{needs finalization}
> {type (needs finalization)}
> 9.2/2 * it is a controlled type, a task type or a protected type; or
> 9.3/2 * it has a component that needs finalization; or
> 9.4/2 * it is a limited type that has an access discriminant whose
>         designated type needs finalization; or
> 9.5/2 * it is one of a number of language-defined types that are
>         explicitly defined to need finalization.

And Protected/Task are obviously limited :

[ARM 3.9.4(5/2)]
> An interface with the reserved word limited, task, protected, or
> synchronized in its definition is termed, respectively, a limited
> interface, a task interface, a protected interface, or a
> synchronized interface. In addition,{interface (synchronized)
> [partial]} {interface (protected) [partial]} {interface (task)
> [partial]} {interface (limited) [partial]} {interface (nonlimited)
> [partial]} {synchronized interface} {protected interface} {task
> interface} {limited interface} {nonlimited interface} all task and
> protected interfaces are synchronized interfaces, and all
> synchronized interfaces are limited interfaces.

If I'm wrong, I do not figure where I'm wrong.