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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,3162283879cdc5f2
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,UTF8
X-Received: by 10.180.109.111 with SMTP id hr15mr2945053wib.1.1369279554950;
        Wed, 22 May 2013 20:25:54 -0700 (PDT)
Path: 
 fw11ni1146wic.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Type vs subtype about visibility of parent's private full
 definition
Date: Thu, 16 May 2013 16:29:13 +0100
Organization: A noiseless patient Spider
Message-ID: <lyk3mzx7sm.fsf@pushface.org>
References: <op.ww383ycoule2fv@cardamome>
Mime-Version: 1.0
Injection-Info: mx05.eternal-september.org;
 posting-host="720834a9e3ef3094259fa78805e56e66";
	logging-data="2153"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/UEhLpHNrxod+0Si6WvUVv3v5w4m+d4CI="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:fF3riBJ9TiMixw7mxq3xcT/XUUI=
	sha1:SkdGsmUnRwIvuieN6vJXPUXBi4o=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Date: 2013-05-16T16:29:13+01:00
List-Id: <comp.lang.ada>

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> I already encountered something similar in the past, and it's back
> again. I can only solve it using a subtype instead of a type‑new where
> I initially want a type‑new, so I'm not happy with using subtype.
>
> The case: a child package don't see the full definition of a type from
> the private part of its parent package when it derives from that type
> as a type‑new.
>
> Below is an example, using a discriminant, which is not required to
> expose the visibility issue, but which is the reason why I'm not happy
> to not be able to derive a type‑new instead of a subtype: I can't
> force static‑check as I expected. If the discriminant was not part of
> the party, I won't bother. That's the reason why the example makes use
> of a discriminant and I see the case as an issue.
>
>
> Example:
>
>
>     package Parents is
>
>        pragma Pure;
>
>        type Discriminant_Type is
>           range 1 .. 5;
>
>        type Instance_Type
>          (Discriminant : Discriminant_Type) is
>           private;
>
>     private
>
>        type Instance_Type
>          (Discriminant : Discriminant_Type) is
>           record
>              Value : Integer;
>           end record;
>
>     end Parents;
>
>     package Parents.Childs is
>
>        pragma Pure;
>
>        subtype Parent_Type is
>           Parents.Instance_Type;
>
>        type Instance_Type is
>           new Parent_Type
>             (Discriminant => 2);

There may or may not be a compiler bug triggered by this form, but I
don't understand why you say "I can only solve it using a subtype
instead of a type‑new where I initially want a type‑new, so I'm not
happy with using subtype" because if I write instead of Parent_Type and
Instance_Type above

   type Instance_Type is
     new Parents.Instance_Type
     (Discriminant => 2);

or

   subtype Instance_Type is
     Parents.Instance_Type
     (Discriminant => 2);

it compiles OK.

>        function Value
>          (Object : Instance_Type)
>           return Integer;
>
>     private
>
>        function Value
>          (Object : Instance_Type)
>           return Integer
>           is (Object.Value); -- << Error here
>
>     end Parents.Childs;
>
>
> I did not check the RM, however I'm blocked if I do this, as GNAT has
> complaints with `is (Object.Value)`, and grumbles:
>
>
>     no selector "Value" for private type derived from "Instance_Type"
>
>
> I can just work around it, defining `Parents.Childs.Instance_Type`
> this way:
>
>
>        subtype Instance_Type is
>           Parent_Type
>             (Discriminant => 2);
>
>
> … instead of this way (as was in the above package definition):
>
>
>        type Instance_Type is
>           new Parent_Type
>             (Discriminant => 2);
>
>
> I may be naive, I believe `Parents.Childs` private part should see the
> full definition of `Parents.Instance_Type` in both case, not only when
> deriving a subtype.
>
> What are your opinions about this issue?