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: a07f3367d7,e51f94f876618e37
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.202.68 with SMTP id kg4mr983399pbc.3.1353055986657;
        Fri, 16 Nov 2012 00:53:06 -0800 (PST)
MIME-Version: 1.0
Path: 
 s9ni19329pbb.0!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!novia!news-hub.siol.net!news1.t-com.hr!newsfeed.CARNet.hr!feeder.erje.net!eu.feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Question[s] about aliased extended return.
Date: Thu, 8 Nov 2012 18:43:15 -0600
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <k7hjj5$kj9$1@munin.nbi.dk>
References: <9bbd99bd-f953-434d-b3c8-6e8a6d5c7dfd@googlegroups.com>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1352421797 21097 69.95.181.76 (9 Nov 2012 00:43:17 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Fri, 9 Nov 2012 00:43:17 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-RFC2646: Format=Flowed; Original
Date: 2012-11-08T18:43:15-06:00
List-Id: <comp.lang.ada>

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:9bbd99bd-f953-434d-b3c8-6e8a6d5c7dfd@googlegroups.com...
>The syntax for the extended return given in the RM
>[ http://www.ada-auth.org/standards/12rm/html/RM-6-5.html ] allows for the 
>usage
> of the keyword ALIASED, with the restriction of "if the keyword aliased is 
> present
>  in an extended_return_object_declaration, the type of the extended return 
> object
>  shall be immutably limited."
>
>The 2012 rationale entry regarding the extended return
> [ http://www.ada-auth.org/standards/12rat/html/Rat12-4-6.html ] says of 
> immutably limited objects:
>* it is an explicitly limited record type,
>* it is a task type, protected type or synchronized interface,
>* it is a non-formal limited private type that is tagged or has an access 
>discriminant with a default expression, [or]
>* it is derived from an immutably limited type.
>
>(1) Doesn't this reduce the usefulness of the extended return?

No. Allowing "aliased" at all was a bug in Ada 2005; we preserved it only 
for compatibility (some GNAT customers used it a lot).

> There are a couple of times building the OpenGL binding where I would have 
> liked to do something like:
> Function some_vector( [params] ) Return Vector_of_points is
> begin
>  Return Result : access Vector_of_points( 1..size_from_params ) do
>    glFunctionPopulatingVector( glEnum_from_params, Result'access )
>  end return;
>end some_vector;
>in order to populate the vector with the requisite data, but this is not 
>allowed.

I presume you meant "aliased" rather than "access" in the return statement 
here.

IMHO, you get what you deserve when you use access parameters rather than 
"in out" parameters. There is no good reason to use an access parameter in a 
routine like Populating_Vector (at least in the Ada part - you might have to 
do all kinds of nasty things in the thin interface).

>(2) Is there a reason this is not allowed? (Thick/thin 'pointer' 
>differences?)

Of course. See the examples in AI05-0053-1. If a return object is a a 
temporary, allowing 'Access to be taken of it causes all kinds problems 
because its lifetime is unusual at best.

> Lastly, the GNAT compiler seems to reject the following, even though the 
> rationale says
> a "explicitly limited record type" qualifies as immutably limited:
>    Type LR is limited record
>      Data : Character:= 'X';
>    End record;
>
>    Function Get_LR Return LR is
>    begin
>        Return Result : aliased LR do
>           null;
>       end return;
>     end Get_LR;
>(3) Is this a bug, or am I just misreading everything?

Looks like a bug to me.

                                   Randy.