Type vs subtype about visibility of parent's private full definition

[Yannick Duchêne (Hibou57)]

Hi all,

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);

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?


--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

[Adam Beneschan]

On Wednesday, May 15, 2013 1:13:00 AM UTC-7, Hibou57 (Yannick Duchêne) wrote:
> Hi all,
>
> 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

> What are your opinions about this issue?

7.3.1(4) says that the Value component should be visible at that point. This is a compiler bug.

-- Adam

[Yannick Duchêne (Hibou57)]

Le Wed, 15 May 2013 16:44:05 +0200, Adam Beneschan <ad...@irvine.com> a
écrit:

> 7.3.1(4) says that the Value component should be visible at that point.
> This is a compiler bug.
>
> -- Adam

Indeed this looks to say it. I would have not thought to look in “7.3.1
Private Operations” as this was not about operation, and “8.3 Visibility”
does not refers to it neither. Sometime it's not that easy to seek in the
RM :p (even using the Index).

So I will go with subtype anyway (have no choice), and will mark this with
a comment like “-- GNAT bug” to remind me (and may be others, who know)
it's not an Ada issue.

Thanks Adam :)

[Marc C]

On Wednesday, May 15, 2013 3:45:24 PM UTC-5, Hibou57 (Yannick Duchêne) wrote:

> So I will go with subtype anyway (have no choice), and will mark this with
> a comment like “-- GNAT bug” to remind me (and may be others, who know)
> it's not an Ada issue.

And also send a writeup on this to rep...@adacore.com so they're aware of it. Include your test program, the LRM references, and maybe a link to this discussion thread.

Since you're not a supported user it's unlikely they'll jump to fix it, but it likely will be fixed at some point.

Marc A. Criley

[Simon Wright]

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.

[Yannick Duchêne (Hibou57)]

Le Thu, 16 May 2013 17:29:13 +0200, Simon Wright <si...@pushface.org> a
écrit:

> 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.

The first does not compile for me with GNAT from GCC 4.8, it fails with
the message given in the original message, which is “no selector "Value"
for private type derived from "Instance_Type"”.

What GNAT flavour did you tried it with? GNAT Pro or GPL or FSF?

[Yannick Duchêne (Hibou57)]

Le Thu, 16 May 2013 22:25:12 +0200, Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:

> Le Thu, 16 May 2013 17:29:13 +0200, Simon Wright <si...@pushface.org> a
> écrit:
>> 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.

Sorry for the previous message, I missed you used `Parents.Instance_Type`
and will try this variant. Anyway, that still seems to be a bug, as the
behaviour should be the same in both cases, using either
`Parents.Instance_Type` or a `Parent_Type` subtype.

[Randy Brukardt]

"Adam Beneschan" <ad...@irvine.com> wrote in message
news:309db8ab-239d-4b06...@googlegroups.com...
...

>> What are your opinions about this issue?
>
>7.3.1(4) says that the Value component should be visible at that point.
>This is a compiler bug.

Humm, I'm not sure that GNAT is wrong here. There is a long tradition of
tests where you might thing components would be available but are not. I'm
not certain if this is one of those cases or not, but I direct your
attention to 7.3.1(5.1/3) [which exists to clarify the language because of a
bug that some Beneschan guy reported with record aggregates].

The reason I said that I'm "not sure" is that this is a very messy area, and
what is supposed to happen depends very much upon the exact example. (I
would blow this all away in my language redesign -- it has wasted far too
much time for its value.)

Randy.

[Adam Beneschan]

On Thursday, May 16, 2013 5:01:02 PM UTC-7, Randy Brukardt wrote:

> ...
>
> >> What are your opinions about this issue?
>
> >7.3.1(4) says that the Value component should be visible at that point.
> >This is a compiler bug.
>
> Humm, I'm not sure that GNAT is wrong here. There is a long tradition of
> tests where you might thing components would be available but are not.

My recollection is that those cases involve multiple derivations where type T1 is declared in a Parent package, type extension T2 is derived from T1 in a package that is not a child of Parent, and T3 is derived from T2 in a child of Parent; although normally the private part and body of Parent.Child would be able to see the private part of Parent, there were some language issues because of the type T2 in the middle, which couldn't inherit all the operations from T1 because they weren't visible at any place. Yannick's example doesn't involve that, so this case shouldn't be as messy.

-- Adam