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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,2153d570c2f03e29
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.224.184.11 with SMTP id ci11mr6007614qab.1.1355653283594;
        Sun, 16 Dec 2012 02:21:23 -0800 (PST)
Received: by 10.49.116.115 with SMTP id jv19mr1946747qeb.21.1355653283579;
 Sun, 16 Dec 2012 02:21:23 -0800 (PST)
Path: 
 k2ni7qap.0!nntp.google.com!fc2no1027552qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sun, 16 Dec 2012 02:21:23 -0800 (PST)
In-Reply-To: <ly7goiz60i.fsf@pushface.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=91.7.77.185;
 posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf
NNTP-Posting-Host: 91.7.77.185
References: <f7a79646-eb34-42c6-b1df-ccbb8c59437f@googlegroups.com>
 <ly7goiz60i.fsf@pushface.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a7a82a85-48e4-4ded-b090-06f62bd3b0b6@googlegroups.com>
Subject: Re: Question about library-level functions
From: AdaMagica <christ-usch.grein@t-online.de>
Injection-Date: Sun, 16 Dec 2012 10:21:23 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Date: 2012-12-16T02:21:23-08:00
List-Id: <comp.lang.ada>

On Sunday, December 16, 2012 10:43:41 AM UTC+1, Simon Wright wrote:
> ytomino writes:
>
> > function alloc return access lifetime.T is
> > begin
> >    return new lifetime.T'(lifetime.Create);
> >    -- lifetime.Finalize may be called here
> > end alloc;
>
> I think that what's happening is that a (limited) temporary lifetime.T
> object is created (on the heap, or perhaps the secondary stack). Its
> access is taken for the return value, and then (because we're leaving
> the scope) it gets finalized.

Looks like so, but IMHO this is illegal. A limited object must be created i=
n-place. (Of course an implementation can do as it likes and create first a=
 temporary object, then copy it to the final one and finalize the temporary=
 *if* the result is as though it was created in-place. But here, it seems l=
ike the same object is finalized twice.)

What may be temporary and copied it the access value and not the accessed o=
bject. It's standard to create an object via an access and return the latte=
r - the object must not be finalized, of course.

Creating via anonymous access is evil - how can ou ever deallocate it? This=
 should be verboten by the language.