Re: Extended return question

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

Adam Beneschan <adam@irvine.com> writes:

> On Jul 10, 4:20 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> "Dale Stanbrough" <MrNoS...@bigpoop.net.au> wrote in message
>>
>> news:MrNoSpam-BCD9C2.17322110072008@news-server.bigpond.net.au...
>>
>> > Georg Bauhaus wrote:
>>
>> >> Dale Stanbrough wrote:
>> >> > The purpose of an extended return is to create the values in-situ
>> >> > without copying.
>>
>> >> _Limited_ objects can be initialized in situ by an aggregate
>> >> or function call  ... :-)
>>
>> > Ah, thanks.  I had misread John Barnes comments on this. Why such a
>> > restriction? Why not allow it for all extended returns on all types?
>>
>> Build-in-place is *allowed* for all objects; it is only *required* for types
>> that always have to be limited (now known as "immutably limited types" (see
>> AI05-0052-1).
>
> Where does the RM say that build-in-place is allowed for all objects?
> The only place I can see that refers to build-in-place for nonlimited
> objects is 7.6(21), and that permission seems to apply only to
> controlled objects.
>
> Also, the language there says that if a function call is assigned into
> a target object, an anonymous object doesn't need to be created if the
> value of the function call can be "safely" created in the target
> object.  But "safely" isn't defined.  If the function could create
> part of the target object and then terminate on an exception, as in
> Dale's original example, is that considered "unsafe", which would mean
> build-in-place isn't allowed for this function call?  If it doesn't
> mean that, what does "safely" mean?

For:

    X := F(...);

the language rules require that X not be modified in case of exceptions
in F.  Of course the type of X is nonlimited here.

- Bob