Re: Dispatch on the result still does not work?

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

On 11 juil, 17:19, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Well, I used to think the way like you do until Ada 2005 introduced limited
> aggregates and initialization of limited objects and their components using
> functions... (:-))
This does not stand for the general case of a function. This is a
specific requirement, which may in some way be compared to the
previoulsy given implementation optimization exemple. The difference
here, is that this is not an implementation optimization, but a “ low
level ” semantic requirement like the support for controling
initialization/adjustement of objects... the kind of aspect which
tipically reside in the private part of a package specification  ;-) .
This is a special subset of what a function may-be, which is not the
same as the general case of a function. Any way, this still handled
separately, this is something standing around the function, this is
not the function. The extended return statement is still a return
statement, which may be used in any others functions... which finally
makes it rather conform to what a function is in its general case.

BTW: Yes, you're right about the value vs the object (I did not get
the good word)

Annotated ARM 7.5 - “ Limited Types ”
> 8.1/2 {AI95-00287-01} {AI95-00318-02} 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.
> -
> 8.a/2Discussion: {AI95-00318-02} 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.
> -
> NOTES
> 9/214 {AI95-00287-01} {AI95-00318-02} 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:

Yes, but how would you initialize a limited type another way, while it
cannot be assigned by copy ? This is a mandatory semantic requirement.
But the function still acts as an initializer expression in the user's
view point.

Annotated ARM 7.5 (again)
> 2.e/2 Discussion: All of these contexts normally require copying; by
> restricting the uses as above, we can require the new object to be
> built-in-place.
> -
> [...]
> -
> 9/214 {AI95-00287-01} {AI95-00318-02} 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:

The requirement is well based