Re: Extended return question

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

On Fri, 11 Jul 2008 02:06:17 -0700 (PDT), christoph.grein@eurocopter.com
wrote:

> On 11 Jul., 09:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 10 Jul 2008 20:43:09 -0400, Robert A Duff wrote:
>>> I don't see any problem here. �The "notion of limited type" is "do not
>>> copy". �In the example below, X is created, then destroyed, then another
>>> X is created, and that becomes the result. �No copying.
>>
>> No, we cannot say that, because
>>
>> A) X is not created until the constructing function returns. There is just
>> no X until that point. The question is *what* was created and destroyed? It
>> is improperly typed, at least.
>>
>> B) On the other hand, if we considered X being created, destroyed and
>> created again, then the name X would resolve into two different objects in
>> the same context. This would either violate the identity semantics of X or
>> be semantically equivalent to an assignment of X.
> 
> I view it this way:
> 
> There is a certain storage region where something (first X) is created
> and then distroyed.

But there cannot be first and second X, when X is limited! The object X is
*one* object. It must be created strictly once. It can change its state,
but it cannot disappear and reappear, that is not state change. So the
question stands: what was created and then destroyed? The following
question is: what is the type of that thing (which the type cannot be T.)

> There is again a certain storage region (may be the same, may be not)
> where the second X is created. Only when the function returns becomes
> this storage region known a the final limited object. No copying.

I don't think that limitmess is only about copying. It is rather about
keeping the identity of the object. The latter implies the former but not
necessarily reverse.

When I see a sequence Initialize - Finalize - Initialize attributed to the
same object, that is a sequence of assignment to me. The storage region
used is in my view irrelevant here. I agree with Adam that "limitness" may
allow moving bit patterns in the memory. It is OK, because the identity of
a limited object is not necessarily the memory address, though an
implementation may choose memory location for this purpose. So the issue
boils down to the meaning of "in-place."

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