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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.42.211.15 with SMTP id gm15mr21138654icb.28.1400699370753; Wed, 21 May 2014 12:09:30 -0700 (PDT) X-Received: by 10.182.165.36 with SMTP id yv4mr92554obb.18.1400699370659; Wed, 21 May 2014 12:09:30 -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!c1no13067679igq.0!news-out.google.com!gi6ni6673igc.0!nntp.google.com!hl10no3133343igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 21 May 2014 12:09:30 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Suggestion: Allow functions returning abstract types in certain situations From: "Dan'l Miller" Injection-Date: Wed, 21 May 2014 19:09:30 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:19954 Date: 2014-05-21T12:09:30-07:00 List-Id: On Wednesday, May 21, 2014 11:10:44 AM UTC-5, Adam Beneschan wrote: > On Wednesday, May 21, 2014 7:52:27 AM UTC-7, Victor Porton wrote: >=20 > > I think the standard should allow functions returning abstract types, The size of an abstract type is not known in this situation. Perhaps you s= hould reconsider your design (and your critique of Ada) to focus on functio= ns returning some variety of *access* to abstract type or abstract type 'C= lass (rather than returning an instance of an abstract type's eventual conc= rete type). > > but we=20 > > can restrict to call such functions ONLY in parent parts of record=20 > > extensions or private extensions. In C++ this is called slicing, which is undefined behavior and which is con= sidered one of the ways to drive off the cliff in C++. Ada should absolute= ly not permit any form of slicing. > Unless you mean "extension aggregates", I'm not sure what you're referrin= g to. An extension aggregate is an aggregate where the parent part is spec= ified as an expression and the extension fields follow the "with" keyword. = So are you referring to something like this? >=20 >=20 >=20 > package Pack1 is > type T1 is abstract tagged record ... end record; > function Func (X : Integer) return T1; -- not currently legal This whole topic seems to be going nowhere fast. The size of T1's eventual= concrete type (i.e., some member of T1'Class) cannot be known by Func (nor= in general by callers of Func). There could be many such eventual concret= e types of T1; hence the insurmountable question will always be: which mem= ber of T1'Class was instantiated concretely?