From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f8a440310f7f2e02 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!2g2000hsn.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Extended return question Date: Thu, 10 Jul 2008 17:03:31 -0700 (PDT) Organization: http://groups.google.com Message-ID: <77279091-112d-46ef-9e26-f83497a66bd5@2g2000hsn.googlegroups.com> References: <4875b7e3$0$6618$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1215734611 9814 127.0.0.1 (11 Jul 2008 00:03:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 11 Jul 2008 00:03:31 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 2g2000hsn.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:1100 Date: 2008-07-10T17:03:31-07:00 List-Id: On Jul 10, 4:20 pm, "Randy Brukardt" wrote: > "Dale Stanbrough" 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)