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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.173.75 with SMTP id bi11mr24613420pac.4.1400688644968; Wed, 21 May 2014 09:10:44 -0700 (PDT) X-Received: by 10.50.79.137 with SMTP id j9mr317603igx.15.1400688644867; Wed, 21 May 2014 09:10:44 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!hl10no3042607igb.0!news-out.google.com!qf4ni5721igc.0!nntp.google.com!c1no12933201igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 21 May 2014 09:10:44 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Suggestion: Allow functions returning abstract types in certain situations From: Adam Beneschan Injection-Date: Wed, 21 May 2014 16:10:44 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:19953 Date: 2014-05-21T09:10:44-07:00 List-Id: On Wednesday, May 21, 2014 7:52:27 AM UTC-7, Victor Porton wrote: > I think the standard should allow functions returning abstract types, but= we=20 > can restrict to call such functions ONLY in parent parts of record=20 > extensions or private extensions. Unless you mean "extension aggregates", I'm not sure what you're referring = to. An extension aggregate is an aggregate where the parent part is specif= ied as an expression and the extension fields follow the "with" keyword. S= o are you referring to something like this? package Pack1 is type T1 is abstract tagged record ... end record; function Func (X : Integer) return T1; -- not currently legal ... package Pack2 is type T2 is new Pack1.T1 with record=20 New_Data : Integer; ... Rec : T2 :=3D (Pack1.Func(N) with New_Data =3D> 0, ...); If that isn't what you mean by "parent parts of record extensions or privat= e extensions", please explain what you mean, preferably with some sample co= de.=20 Although at first glance this appeared reasonable to me, I think there's a = huge problem: how would you write the *body* of the function? The function= would have to return something. The language doesn't allow you to declare= objects of an abstract type, so Func could not declare a local variable "R= esult" of type T1 that it could return. Nor could it return an aggregate, = which involves creating a temporary object. In my view, the language model= depends heavily on the assumption that an object can never be created whos= e tag refers to an abstract type; allowing the rule to *ever* be relaxed co= uld be disastrous. For extension aggregates, perhaps an alternative would be to allow a *proce= dure* with an OUT parameter as the parent part of an extension aggregate? = Something like package Pack1 is type T1 is abstract tagged record ... end record; procedure Setup (Obj : out T1; X : Integer); -- not currently lega= l and then Rec : T2 :=3D (Pack1.Setup(**THIS**, N) with New_Data =3D> 0, ...); This wouldn't require creating an object of type T1 at any point. In effec= t, the program would create an object Temp of type T2, use T1(Temp) [view c= onversion] as a parameter to Setup which presumably would initialize some f= ields declared in T1, then initialize the extension fields. [Note that T1(= Temp) does not create an object whose tag is the tag of T1; the object's ru= n-time type is still T2, but the program is now working with a *view* of th= at object that only allows the fields declared for T1 to be visible.] The = tricky part would be coming up with a syntax; perhaps the "use" keyword cou= ld be given a new job? Rec : T2 :=3D (use Pack1.Setup(T2, N) with New_Data =3D> 0, ...); Here I used "use" to indicate that we're going to use a procedure to help s= et up the fields, rather than using an expression. (Or maybe "procedure" i= nstead of "use" would work too?) As for how to specify the "temporary obje= ct" that would be passed as a parameter, I used the type name. Some detail= s would have to be worked out, such as whether and when Initialize would be= called if T2 is controlled, build-in-place semantics, and what happens if = there are discriminants involved. -- Adam