Re: Generic package parameters not externally visible : what's the rational ?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:10eygvuzeit9g.xwy2wanxoxgf$.dlg@40tude.net...
> On Tue, 27 Oct 2009 16:08:09 -0500, Randy Brukardt wrote:
...
>> I'm not sure that it "makes perfect sense" for them to be visible: it 
>> would
>> surely increase the chance of name collisions outside of the package.
>
> Sorry, but that is a "generic" property of anything declared in a generic
> package. Two instances of the same generic packages always collide when
> "use"-ed.

No, I was thinking of name collisions when the formal and actual have the 
same name (that is very common for subprogram parameters and is not uncommon 
in generic as well). If the formal is also visible, you end up with two 
things with the same name. Something like:

   generic
       type Int is range <>;
   package Gen is
       ...
   end Gen;

   with Gen;
   package Test is
       type Int is range ...;
       package My_Gen is new Gen (Int);
   end Test;

   with Test;
   procedure Check is
      use Test, Test.Gen;
      Obj : Int; -- (1)
   ...

(1) is legal by the current rules, but if the formal was visible, it would 
become illegal because there would be two Int's visible. That would become 
worse if any of the proposals for integrated instantiations are adopted, 
because both Ints would be visible in the same scope, and thus use Test 
would become ineffective: exactly the reverse of what is wanted from an 
integrated instantiation.

...
>> That's clear from the
>> syntax (they're outside the package). You're going to say that 
>> discriminants
>> are outside of the type, too, but they're also visible. I can't argue 
>> with
>> that beyond saying that that placement of discriminants is just awful; I
>> place them in the wrong place and continually forget to include them in
>> aggregates because they're well away from the other components.
>
> That depends on the mental model of the discriminant. If the discriminant
> is a type constraint, then you are right. But in Ada this concept, if ever
> existed, has been eroded. Presently discriminant is merely an immutable
> component. I am also in favor the "constraint" model, and yes, in this
> model it would be reasonable to make discriminants invisible, e.g. when
> they are used for construction and then dropped. But that is not the Ada
> model now.

...other than for Unchecked_Unions, and even there the model is incomplete. 
(You can reference the discriminant in a context where it can be determined, 
such as for a constrained object, even though it is not stored anywhere. But 
you can't reference it if the object is unconstrained.)

                                    Randy.