From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:ae9:e404:0:b0:6bb:d8c0:381c with SMTP id q4-20020ae9e404000000b006bbd8c0381cmr19659119qkc.459.1662041512683; Thu, 01 Sep 2022 07:11:52 -0700 (PDT) X-Received: by 2002:a81:de4f:0:b0:340:c3d1:3ef1 with SMTP id o15-20020a81de4f000000b00340c3d13ef1mr20673028ywl.509.1662041403305; Thu, 01 Sep 2022 07:10:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 1 Sep 2022 07:10:03 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2a01:e0a:810:89e0:2863:e1f:40fd:f3da; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 2a01:e0a:810:89e0:2863:e1f:40fd:f3da References: <67b32db0-c4db-466c-ac13-e597e008c762n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <401d6f59-2c28-4dd5-9fa6-fccf33b6d645n@googlegroups.com> Subject: Re: Calling inherited primitive operations in Ada From: Emmanuel Briot Injection-Date: Thu, 01 Sep 2022 14:11:52 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5115 Xref: reader01.eternal-september.org comp.lang.ada:64256 List-Id: I have seen quite a number of cases of needing the subtype like Dmitry was = showing. In a small number of cases, those were actual bugs in GNAT, but mo= st of the time the compiler was correct. Mostly, you start to see the issue when you have generic packages that have= formal generic packages. Here is a quick example and the corresponding compiler error message. In Ma= in, there is no way to see T. Of course, I can use Integer_Signature directly, but this is an issue. - if I rename Integer_Signature then I have to change a lot of places in= my code (The aliasing that Dmitry was talking about) with Signature; generic with package Sign is new Signature (<>); package Algo is procedure Compute (V : Sign.T) is null; end Algo; with Algo; with Signature; package Lib is package Integer_Signature is new Signature (Integer); package Integer_Algo is new Algo (Integer_Signature); end Lib; with Lib; procedure Main is V : Lib.Integer_Algo.Sign.T; -- main.adb:3:24: "Sign" is not a visible entity of "Integer_Algo" begin null; end Main; generic type T is private; package Signature is end Signature; There are more interesting examples, somehow this one doesn't seem that bad= . So here is another one: generic type T is private; package Gen is end Gen; with Gen; generic type T is private; with package Must_Match is new Gen (T); with package Need_Not_Match is new Gen (<>); package Gen2 is V1 : Must_Match.T; -- "T" is not a visible entity of "Must_= Match" V2 : Need_Not_Match.T; -- instance of same package, but this time T= is visible end Gen2; with Gen, Gen2; procedure P2 is package G is new Gen (Integer); package G2 is new Gen2 (Integer, G, G); begin null; end P2; I dug out the explanation that Tucker Taft once sent to the Ada-Comment mai= ling list (2019-11-14): <<< 10/2 {AI95-00317-01} The visible part of a formal package includes the first lis= t of basic_declarative_items of the package_specification. In addition, for= each actual parameter that is not required to match, a copy of the declara= tion of the corresponding formal parameter of the template is included in t= he visible part of the formal package. If the copied declaration is for a f= ormal type, copies of the implicit declarations of the primitive subprogram= s of the formal type are also included in the visible part of the formal pa= ckage. 10.a/2 Ramification: {AI95-00317-01} If the formal_package_actual_part is (<>), th= en the declarations that occur immediately within the generic_formal_part o= f the template for the formal package are visible outside the formal packag= e, and can be denoted by expanded names outside the formal package.If only = some of the actual parameters are given by <>, then the declaration corresp= onding to those parameters (but not the others) are made visible. 10.b/3 Reason: {AI05-0005-1} We always want either the actuals or the formals of a= n instance to be nameable from outside, but never both. If both were nameab= le, one would get some funny anomalies since they denote the same entity, b= ut, in the case of types at least, they might have different and inconsiste= nt sets of primitive operators due to predefined operator =E2=80=9Creemerge= nce.=E2=80=9D Formal derived types exacerbate the difference. We want the i= mplicit declarations of the generic_formal_part as well as the explicit dec= larations, so we get operations on the formal types. =20 >>>