Version 1.5 of ai05s/ai05-0178-1.txt

Unformatted version of ai05s/ai05-0178-1.txt version 1.5
Other versions for file ai05s/ai05-0178-1.txt

!standard 7.5(3/2)          10-06-07 AI05-0178-1/03
!standard 7.5(6/2)
!class binding interpretation 09-10-29
!status Amendment 201Z 09-12-11
!status WG9 Approved 10-06-18
!status ARG Approved 11-0-0 09-11-07
!status work item 09-10-29
!status received 09-10-28
!priority Low
!difficulty Easy
!qualifier Omission
!subject Incomplete views are limited
!summary
Incomplete views are always limited, irrespective of whether the completion is limited or nonlimited.
!question
A problem was identified in an example recently posted on ada-comment, illustrated by the following example:
package Pkg1 is type T is ... ; end Pkg1;
limited with Pkg1; package Pkg2 is procedure P (X1, X2 : access Pkg1.T); end Pkg2;
package body Pkg2 is procedure P (X1, X2 : access Pkg1.T) is begin X1.all := X2.all; -- legal? end P; end Pkg2;
Is this assignment legal? (No.) It appears that neither the freezing rules nor 3.10.1(10/2) address this situation.
!response
We clearly want to disallow the assignment. If there is any doubt about this, consider the case where the complete view of Pkg1.T is limited.
Therefore, an incomplete view of a type should be defined to be limited.
!wording
Modify 7.5(3/2):
A {view of a} type is limited if it is one of the following:
Add after 7.5(6/2):
* an incomplete view;
!discussion
We add "a view of" to the lead-in in order that we don't have a conflict between talking about views and types: it would be weird to say that a type is <something> if it is a <something else> view. Note that "incomplete type" is generally used to mean an incomplete view declared by an incomplete_type_declaration (not any other way).
This is OK, as limitedness has always been about views. It's not bad to reiterate that limitedness is a property that can change depending on where you are - as a static semantics rule it is not 100% clear whether AI05-0080-1 applies (it does).
It might appear that a similar problem could occur in other ways, for instance by doing a comparison. But an incomplete_type_declaration does not define any operators, and a limited view does not include any operators, so the comparison operator would not be visible and thus the program would be illegal anyway.
3.10.1(2.1/2) actually says that an incomplete view is limited. But that is not where all other limited views are defined, so it is confusing (obviously it confused the questioner and the original author of this AI).
!corrigendum 7.5(3/2)
Replace the paragraph:
A type is limited if it is one of the following:
by:
A view of a type is limited if it is one of the following:
!corrigendum 7.5(6/2)
Insert after the paragraph:
the new paragraph:
!ACATS Test
Consider a ACATS B-Test like the example in the question.
!appendix

From: Steve Baird
Sent: Thursday, October 29, 2009  12:24 AM

!summary
An incomplete view of a type is limited.

!problem
Gary Dismukes identified a problem in an example Adam Beneschan recently posted
on ada-comment, illustrated by the following example:

  package Pkg1 is
    type T is ... ;
  end Pkg1;

  limited with Pkg1;
  package Pkg2 is
    procedure P (X1, X2 : access Pkg1.T);
  end Pkg2;

  package body Pkg2 is
    procedure P (X1, X2 : access Pkg1.T) is
    begin
        X1.all := X2.all; -- legal?
    end P;
  end Pkg2;

We clearly want to disallow the assignment.
If there is any doubt about this, consider the case where the complete view of
Pkg1.T is limited.

It appears that neither the freezing rules nor 3.10.1(10/2) address this
situation. An incomplete view of a type should therefore be defined to be
limited.

!wording

Add after 7.5(6/2) [as another bulleted list item]:

  - an incomplete type;

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

From: Tucker Taft
Sent: Thursday, October 29, 2009  7:42 AM

This appears to be a problem even with "normal"
incomplete types, since the only limitation on the use of objects of an
incomplete type now in 3.10.1(10/2) has to do with their use as a prefix.  How
did we miss this?

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

From: Steve Baird
Sent: Thursday, October 29, 2009  10:54 AM

Was this an unintended consequence of loosening up the freezing rules for
incomplete types in order to allow

    limited with P;
    with P_Full_View_Client;
    procedure Foo (X : access P.Some_Type) is
    begin
        P_Full_View_Client (Param => X.all);
    end Foo;

?

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

From: Randy Brukardt
Sent: Thursday, October 29, 2009  12:03 PM

>How did we miss this?

I don't think we did per-se. I recall you telling us that incomplete views are
always limited. (That's why I immediately went there when Steve raised the
question to me privately yesterday.) The problem is that never made it into the
wording. I suspect that someone convinced themselves that the problem case could
never happen. Of course, Steve is better than the rest of us proving such
assumptions are wrong...

>Add after 7.5(6/2) [as another bulleted list item]:
>
>  - an incomplete type;

I think you mean "an incomplete view" here, because we surely want it to apply
to your example and there are no incomplete *types* anywhere to be seen in it.

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

From: Steve Baird
Sent: Thursday, October 29, 2009  12:48 PM

I considered exactly the wording you've suggested.

As you know, we often talk about a type when we are really talking about a view
of a type.

7.5(3/2) is one such case:

   A type is limited if it is one of the following:
     -blah
     -blah
     -blah

It seemed odd to me to start talking explicitly about views for just one member
of this bulleted list when the others (e.g.,
    "a type with the reserved word blah, blah, or blah in its definition"
) do this implicitly.

Do we really want something like
    A type is blah if it is
     - a fooish view
?

You are saying that it is not ok to use the term "incomplete type"
as shorthand for "incomplete view of a type" in this context.
If this is correct, then I agree that we need to use your suggested wording.

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

From: Randy Brukardt
Sent: Thursday, October 29, 2009  1:27 PM

> As you know, we often talk about a type when we are really talking
> about a view of a type.

Right. I hate that, but it's too late to fix.

...
> It seemed odd to me to start talking explicitly about views for just
> one member of this bulleted list when the others (e.g.,
>     "a type with the reserved word blah, blah, or blah in its
> definition"
> ) do this implicitly.

I know, but it can't be helped here.

> Do we really want something like
>     A type is blah if it is
>      - a fooish view
> ?

We have no choice. It would be better to change the lead-in as well:

A {view of a} type is limited if it is:

I think that would actually be a good idea irrespective of this other issue,
because limitedness is so tied to views. After all, it is quite possible to have
types that limitedness varies by views, but you can't tell that from this
wording, and most Ada newbys (and even some experts) miss that critical point.
(I forget it from time-to-time, an in-your-face reminder would be welcome.) But
I've lost that argument before in similar cases (specifically for 3.9.3(4/2)).
Maybe the bizarreness of the required wording will tip the scales.

> You are saying that it is not ok to use the term "incomplete type"
> as shorthand for "incomplete view of a type" in this context.
> If this is correct, then I agree that we need to use your suggested
> wording.

The definition of "incomplete type", supposedly in 3.2(4.1/2) is very vague. We
formally define "incomplete view" and there is of course an
incomplete_type_declaration. I've always used "incomplete type" to mean the
incomplete view of a type declared by a "incomplete_type_declaration", but I see
that you could read 3.2(4.1/2) more broadly than that. I never, ever use
"incomplete type" in normative wording unless I do *not* mean to include
incomplete views that come from limited views (and that hardly ever happens). I
really don't want to get into an argument about the meaning of "incomplete
type", anymore than I want to figure out precisely what a "private type" is (I
would may the same argument there: something that has "is private" in its
declaration - but again you could argue for a broader view given the vague
wording off 3.2(4.1/2). I'd argue that we wouldn't need the terms "incomplete
view" and "partial view" if we were just going to say they're the same as
"incomplete types" and "private types". But YMMV.

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

From: Tucker Taft
Sent: Thursday, October 29, 2009  1:56 PM

Adding "view of a" seems to solve the problem nicely.

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

From: Pascal Leroy
Sent: Sunday, November 15, 2009  8:33 AM

> I don't think we did per-se. I recall you telling us that incomplete views
> are always limited. (That's why I immediately went there when Steve raised
> the question to me privately yesterday.) The problem is that never made it
> into the wording.

I read in 3.10.1(2.1/2): "An incomplete view of a type is a limited view of
the type (see 7.5)".  This seems exactly right to me, although I could see
an argument for putting this rule in 7.5 rather than hiding it here.

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

Questions? Ask the ACAA Technical Agent