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,WEIRD_PORT autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada design bug or GNAT bug? Date: Sat, 20 Jun 2015 21:42:44 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1434854565 9856 24.196.82.226 (21 Jun 2015 02:42:45 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sun, 21 Jun 2015 02:42:45 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:26392 Date: 2015-06-20T21:42:44-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:yo94phsbcvht$.1bktwe2qoqntt$.dlg@40tude.net... > Is it intentional that there is no way to derive from a more specific type > privately? A key design pattern is no more possible in GNAT GPL 2015: > > package P1 is > type T1 is tagged null record; > type T2 is new T1 with null record; > function Foo return not null access T2; Anonymous access types are evil; there cannot be a "key design" pattern using them. :-) Since you did use an anonymous access result, you have a function with a "controlling access result". This works much like function Bar return T2; which has a "controlling result". If you had used a named access type, you definitely would not have this problem - 3.9.3(10/3) only applies to anonymous access types. > end P1; > > with P1; use P1; > package P2 is > type T3 is new T1 with private; > private > type T3 is new T2 with null record; > overriding function Foo return not null access T3; -- Illegal! > end P2; > > p2.ads:5:09: type must be declared abstract or "Foo" overridden > p2.ads:5:09: "Foo" has been inherited from subprogram at p1.ads:4 > p2.ads:6:24: private function with tagged result must override > visible-part > function > p2.ads:6:24: move subprogram to the visible part (RM 3.9.3(10)) > > [ Since when access types became tagged? ] They're not "tagged", but they dispatch as if they were tagged (if anonymous). So they have to follow the same rules as with a tagged type. > There seem no way to implement T3 by deriving from T2. *Any* declaration > of > Foo would be illegal. > > 1. It cannot be inherited > 2. A public declaration is not an overriding > 3. A private declaration must be public Right. The same would happen for the function Bar that I noted above. But that just means that you can't hide T2. There's no good reason to not declare T3 as type T3 is new T2 with private; and that eliminates any problem (you can then declare Foo anywhere you want in the spec). Anyway, it's definitely *not* a design bug. It follows from the requirement that one can dispatch on the result; we can't allow dispatching to functions that return the wrong kind of thing. 6.5(8.1/3) would require any attempt to return the wrong kind of thing to raise Constraint_Error. That requires a new body and automatically generating one that always raises Constraint_Error would be madness. Thus the "shall be overridden" requirement. Perhaps you didn't want to dispatch on the result, but too bad, that's how anonymous access designated tagged types is defined (it's supposed to be an exact equivalent of anonymous access parameters). If there's a design bug, it's the existence of anonymous access types at all with these unusual special properties. Anyway, there are three workarounds: (1) don't hide T2; (2) use a named access type; (3) use a class-wide type for the return (thus turning off dispatching). Randy.