!standard 3.7.1(7/2)                                          07-03-27    AI05-0041-1/01
!class binding interpretation 07-03-27
!status work item 07-03-27
!status received 07-03-27
!priority Medium
!difficulty Hard
!qualifier Omission
!subject Can a derived type be a partial view?
!summary

** TBD.

!question

It seems that the meaning of "partial view" in 3.7.1(7/2) is either
obscure or too narrow. The ACATS 2.6 test contains an subtest like the following,
for which the legality is not obvious.

package B371001_1 is
    type T is private;
private
    type T (D : Integer := 0) is null record;
end B371001_1;

package B371001_1.Child_2 is
    type T is new B371001_1.T;
    type Ptr1 is access all T;
    subtype S1A is Ptr1 (1); -- ERROR: [1]
private
    subtype S1B is Ptr1 (2); -- ERROR: [2]

    type Ptr2 is access constant T;
    subtype S2 is Ptr2 (3); -- ERROR: [3]

    type Ptr3 is access T;
    P3 : Ptr3 (0); -- OK [4]
end B371001_1.Child_2;

The error at [1] occurs because only the partial view of B371001_1.T is
visible in the visible part, and thus that is all that is derived. That view
doesn't have discriminants, so the constraint is illegal.

On the other hand, the private part has more visibility into the parent, and it can see
that the type has discriminants.

The errors at [2] and [3] are supposed to be because the type has defaulted
discriminants; since that only applies to general access types, [4] is OK.

However, that brings up the question of whether this type has a partial
view. The test writer surely expected it to behave as if it does (by
expecting some constraints to be able to see the discriminants, and thus be
legal). In that case, the purpose of this rule (to prevent problems with
discriminant constraints that point at unconstrained objects) would require
the partial view rule to be enforced. What is the intent?

!recommendation

(See Summary.)

!wording

** TBD.

!discussion

Clearly, the type in the question has two views (7.3.1(4/1) explicitly states that additional
information can be made visible for a derived type). So, the problem that 3.7.1(7/2) is
intended to prevent is present for this type. It needs to apply.

Defining this kind of type to be a partial view would surely work, but it would trigger a
number of other rules (for instance, about completions, freezing, and representation clauses)
which might be harmful. As such, doing that seems to be too dangerous to contimplate,
especially for a Corrigendum level change.

Changing 3.7.1(7/2) also requires changing the matching 4.8(6/2).


--!corrigendum 10.1.2(20/2)



!ACATS test

The test case in the question should be replaced in the ACATS 3.0 test B371001 (it has been
removed until this AI is resolved).

!appendix

From: Randy Brukardt
Date: Monday, March 23, 2007  7:07 PM

It seems to me that the meaning of "partial view" in 3.7.1(7/2) [and I
believe that there are similar rules elsewhere in the language] is either
obscure or too narrow. I was updating the ACATS test for the Corrigendum
version of this rule, and I ran across the following example:

package B371001_1 is
    type T is private;
private
    type T (D : Integer := 0) is null record;
end B371001_1;

package B371001_1.Child_2 is
    pragma Elaborate_Body;

    type T is new B371001_1.T;
    type Ptr1 is access all T;
    subtype S1A is Ptr1 (1); -- ERROR: [1]
private
    subtype S1B is Ptr1 (2); -- ERROR: [2]

    type Ptr2 is access constant T;
    subtype S2 is Ptr2 (3); -- ERROR: [3]

    type Ptr3 is access T;
    P3 : Ptr3 (0); -- OK [4]

end B371001_1.Child_2;

The error at [1] occurs because only the partial view of B371001_1.T is
visible in the visible part, and thus that is all that is derived. That view
doesn't have discriminants, so the constraint is illegal.

OTOH, the private part has more visibility into the parent, and it can see
that the type has discriminants.

The errors at [2] and [3] are supposed to be because the type has defaulted
discriminants; since that only applies to general access types, [4] is OK.

However, that brings up the question of whether this type has a partial
view. The test writer surely expected it to behave as if it does (by
expecting some constraints to be able to see the discriminants, and thus be
legal). In that case, the purpose of this rule (to prevent problems with
discriminant constraints that point at unconstrained objects) would require
the partial view rule to be enforced. (Thanks to Pascal for this insight.)

However, I'm now wondering if the whole idea is wrong here. This is a
derived type, not a private type, and it doesn't get additional operations
at a later point like a private type. (Right?). In that case, this type
never would have (visible) discriminants, and all of the constraints are
illegal. I know that in type extensions, you can lose the ability to access
parent components that you can regain with a type conversion, and this seems
to be a similar case.

Probably the test ought to be structured with a new type in the private
part:

package B371001_1.Child_2 is
    pragma Elaborate_Body;

    type T is new B371001_1.T;
    type Ptr1 is access all T;
    subtype S1A is Ptr1 (1); -- ERROR: [1]
private

    type TT is new B371001_1.T;
    type Ptr2 is access all TT;
    subtype S2 is Ptr2 (2); -- ERROR: [2]

    type Ptr2 is access constant TT;
    subtype S3 is Ptr3 (3); -- ERROR: [3]

    type Ptr4 is access TT;
    P4 : Ptr4 (0); -- OK [4]

end B371001_1.Child_2;


No one can see the constrained view of TT, so then the original intent
holds, and there isn't a problem with the language wording (only the test).

Thoughts? Which of these lines of logic is correct?

****************************************************************

From: Gary Dismukes
Date: Friday, March 23, 2007  7:08 PM

> However, that brings up the question of whether this type has a partial
> view. The test writer surely expected it to behave as if it does (by
> expecting some constraints to be able to see the discriminants, and thus be
> legal). In that case, the purpose of this rule (to prevent problems with
> discriminant constraints that point at unconstrained objects) would require
> the partial view rule to be enforced. (Thanks to Pascal for this insight.)

Hmm, I'm not sure whether the RM defines such a derived type to be a partial
view, but it seems that it should.  (Not obvious to me how to derive that,
so to speak, especially late on a Friday afternoon;).

> However, I'm now wondering if the whole idea is wrong here. This is a
> derived type, not a private type, and it doesn't get additional operations
> at a later point like a private type. (Right?). In that case, this type
> never would have (visible) discriminants, and all of the constraints are
> illegal. I know that in type extensions, you can lose the ability to access
> parent components that you can regain with a type conversion, and this seems
> to be a similar case.

No, derived types definitely do (or can) get additional operations at a later
point, based on what's visible from the parent type.  That's explicitly covered 
by 7.3(4/1).

> Probably the test ought to be structured with a new type in the private
> part:

You could, though it doesn't seem that you should if the rules work out OK.

Seems better to confirm whether the rules should apply to the test as
written before revising the test, rather than skirting the issue.

> package B371001_1.Child_2 is
>     pragma Elaborate_Body;
> 
>     type T is new B371001_1.T;
>     type Ptr1 is access all T;
>     subtype S1A is Ptr1 (1); -- ERROR: [1]
> private
> 
>     type TT is new B371001_1.T;
>     type Ptr2 is access all TT;
>     subtype S2 is Ptr2 (2); -- ERROR: [2]
> 
>     type Ptr2 is access constant TT;
>     subtype S3 is Ptr3 (3); -- ERROR: [3]
> 
>     type Ptr4 is access TT;
>     P4 : Ptr4 (0); -- OK [4]
> 
> end B371001_1.Child_2;
> 
> 
> No one can see the constrained view of TT, so then the original intent
> holds, and there isn't a problem with the language wording (only the test).

The revised version certainly looks correct, but I think the original
is as well (or at least I believe I can see an argument for that).

> Thoughts? Which of these lines of logic is correct?

See above.

****************************************************************

From: Randy Brukardt
Date: Friday, March 23, 2007  8:38 PM

...
> Hmm, I'm not sure whether the RM defines such a derived type to be a partial
> view, but it seems that it should.  (Not obvious to me how to derive that,
> so to speak, especially late on a Friday afternoon;).

It certainly doesn't, because 7.3(4) defines partial view in terms of the
syntax entities private_type_declaration and private_extension_declaration.
So I don't think any amount of derivation (pun not intended - ED) is going to
change that, on Friday evening, Monday morning, or any other day...

> > However, I'm now wondering if the whole idea is wrong here. This is a
> > derived type, not a private type, and it doesn't get additional operations
> > at a later point like a private type. (Right?). In that case, this type
> > never would have (visible) discriminants, and all of the constraints are
> > illegal. I know that in type extensions, you can lose the ability to access
> > parent components that you can regain with a type conversion, and this seems
> > to be a similar case.
>
> No, derived types definitely do (or can) get additional operations at a later
> point, based on what's visible from the parent type.  That's explicitly covered
> by 7.3(4/1).

You mean 7.3.1(4/1), and you are right, I had forgotten about that.

That means that the definition of partial view is suspect, surely in regards
to 3.7.1(7/2), and probably other rules as well.

> > Probably the test ought to be structured with a new type in the private
> > part:
>
> You could, though it doesn't seem that you should if the rules
> work out OK.
>
> Seems better to confirm whether the rules should apply to the test as
> written before revising the test, rather than skirting the issue.

Well, actually, the rule with the ACATS is that if there is enough doubt for
it to go to the ARG, then we don't include the cases in the test suite.
There is no reason to encourage implementers to do the something that might
turn out to be the wrong thing, depending on what the ARG decides.
I can try to guess what the ARG will decide, but I'm not always going to be
right about that. I've got three tests already on a limbo list waiting for
AI05-0008 and AI05-0028 to be completed, and this test can be added to it.

Sounds like we need an AI to define that a type derived from a partial view
is a partial view if there is a place within its immediate scope where the
full view of the parent type is visible. Or something like that. Gotta worry
about the effect on other rules that depend on partial views, though (should
rep. clauses be illegal on such a type until the private part??? Etc.)

****************************************************************

From: Pascal Leroy
Date: Monday, March 26, 2007  1:49 AM

> Sounds like we need an AI to define that a type derived from 
> a partial view is a partial view if there is a place within 
> its immediate scope where the full view of the parent type is 
> visible. Or something like that. Gotta worry about the effect 
> on other rules that depend on partial views, though (should 
> rep. clauses be illegal on such a type until the private part??? Etc.)

I agree that we need an AI.

My initial reaction when Randy asked that question in private email was,
of course this type has a partial view: at the place of its declaration
you don't know everything about it, and it's only in the private part that
you find out what the type really is.  So one hopes that, in the visible
part, the type is considered composite (last sentence of 3.2(4.1/2)) even
if the full view turns out to be an elementary type.

On second thoughts it is really a strange partial view, though, because it
doesn't "require completion" (in the sense of 3.11.1(1/1)) so it is
"completely defined" at birth (see 3.11.1(8)).  I wouldn't be surprised if
some rules in the RM were written with the (apparently incorrect)
assumption that "is a partial view" implies "is not completely defined".

****************************************************************