Re: Extended return question

[Adam Beneschan <adam@irvine.com>]

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?

                                  -- Adam

(Note: I will not see any response until 7/22)