Re: Calling inherited primitive operations in Ada

[Emmanuel Briot <briot.emmanuel@gmail.com>]

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 most 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 Main, 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 mailing list (2019-11-14):

<<<
10/2
{AI95-00317-01} The visible part of a formal package includes the first list of basic_declarative_items of the package_specification. In addition, for each actual parameter that is not required to match, a copy of the declaration of the corresponding formal parameter of the template is included in the visible part of the formal package. If the copied declaration is for a formal type, copies of the implicit declarations of the primitive subprograms of the formal type are also included in the visible part of the formal package.
10.a/2
Ramification: {AI95-00317-01} If the formal_package_actual_part is (<>), then the declarations that occur immediately within the generic_formal_part of the template for the formal package are visible outside the formal package, and can be denoted by expanded names outside the formal package.If only some of the actual parameters are given by <>, then the declaration corresponding 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 an instance to be nameable from outside, but never both. If both were nameable, one would get some funny anomalies since they denote the same entity, but, in the case of types at least, they might have different and inconsistent sets of primitive operators due to predefined operator “reemergence.” Formal derived types exacerbate the difference. We want the implicit declarations of the generic_formal_part as well as the explicit declarations, so we get operations on the formal types.  
>>>