Version 1.9 of ai05s/ai05-0151-1.txt

Unformatted version of ai05s/ai05-0151-1.txt version 1.9
Other versions for file ai05s/ai05-0151-1.txt

!standard 3.10.1(8/2)          10-06-09 AI05-0151-1/07
!standard 3.10.1(8.2/2)
!standard 3.10.1(9.1/2)
!standard 3.10.1(9.2/2)
!standard 3.10.1(10/2)
!standard 3.10.1(13/2)
!class Amendment 09-04-29
!status Amendment 2012 10-08-10
!status ARG Approved 10-0-0 10-06-19
!status work item 09-12-12
!status ARG Approved 11-0-0 09-11-08
!status work item 09-04-29
!status received 09-04-29
!priority High
!difficulty Hard
!subject Allow incomplete types as parameter and result types
!summary
Make limited views of packages more useful by allowing more use of the incomplete types they make visible.
!problem
The limited with clause makes incomplete views of types visible. Tagged incomplete types are useful for formal parameters, but most other incomplete types are pretty much useless, except as the designated type of an access type. It would be nice if a type declared in a package named in a limited with clause could be used somehow, if only as a parameter type.
!proposal
Incomplete types may be used as formal parameter and result types, so long as they are fully defined at the point of call and at the point where the body is defined.
Incomplete types may not be used for components or objects.
For tagged incomplete types, we will continue to permit them as parameters even in calls and in a body, provided the incomplete type comes from a limited view of a package, rather than from an incomplete type declaration. For non-tagged incomplete types, they will not be permitted in calls or in a body. If the parameter or result type was incomplete at the point of declaration, all calls or the body must be within the scope of a non limited view of the package defining the type.
!wording
Revise 3.10.1(5/2 - 10/2):
A name that denotes an incomplete view of a type may be used as follows:
* as the subtype_mark in the subtype_indication of an
access_to_object_definition; the only form of constraint allowed in this subtype_indication is a discriminant_constraint (a null_exclusion is not allowed);
* as the subtype_mark in the subtype_indication of a
subtype_declaration; the subtype_indication shall not have a null_exclusion or a constraint;
* as the subtype_mark in an access_definition{;}[.]
{* as the subtype_mark defining the subtype of a parameter or result
in a profile occurring within a basic_declaration.
AARM Ramification: But not in the profile for a body.}
If such a name denotes a tagged incomplete view, it may also be used:
* as the subtype_mark defining the subtype of a parameter in [a
formal_part] {the profile for a subprogram_body, entry_body, or accept_statement};
* as the prefix of an attribute_reference whose attribute_designator
is Class; such an attribute_reference is restricted to the uses allowed here; it denotes a tagged incomplete view.
[If such a name occurs within the declaration list containing the completion of the incomplete view, it may also be used:
* as the subtype_mark defining the subtype of a parameter or result
of an access_to_subprogram_definition or an access_definition for an access-to-subprogram type.]
If any of the above uses occurs as part of the declaration of a primitive subprogram of the incomplete view, and the declaration occurs immediately within the private part of a package, then the completion of the incomplete view shall also occur immediately within the private part; it shall not be deferred to the package body.
No other uses of a name that denotes an incomplete view of a type are allowed.
A prefix that denotes an object shall not be of an incomplete view. {An actual parameter in a call shall not be of an untagged incomplete view. The result object of a function call shall not be of an incomplete view. A prefix shall not denote a subprogram having a formal parameter of an untagged incomplete view, nor a return type that is an incomplete view.}
Add after 3.10.1(13) (this is a new note):
A name that denotes an object of an incomplete view is defined to be of a limited type. Hence, the target of an assignment statement shall not be of an incomplete view.
!discussion
This proposal originally focused on a concern that a "limited with" naming a package with named access types forces the use of a lot of explicit conversion and/or anonymous access types in the clients. We originally proposed to allow "incomplete access types" to be used as formal parameters and result types, to avoid the need for all of the conversion. However, after analysis of the issues involved, it became clear that it was possible to generalize, and in some ways simplify, the proposal by allowing the use of any incomplete type as a parameter or result type, provided that the full definition was available at the point of call or at the definition of the body of the subprogram.
An incomplete type is OK as a parameter or result since, until there is a call, there is no need to know the representation of the type. This is in contrast to the case with components, where an aspect clause would need to be obeyed to ensure that streaming, aliased objects, etc., work as expected.
Currently compilers generally do know the representation of the parameters and result at the point of declaration of a subprogram (though not for access-to-subprogram declarations). However, it should be possible to handle the lack of such representation information by having the compiler implicitly create a local access-to-subprogram type at the point of call, and then call through that, using only the address of the subprogram with incomplete types in its declaration, while determining the parameter passing mechanism from the access-to-subprogram type.
Note that we have chosen to allow incomplete types as function results, even though we restricted tagged incomplete types to being parameters only. This seems inconsistent. Why should tagged incomplete types be more restrictive than incomplete types in general? Well, they shouldn't be, so with this proposal, the only advantage a tagged incomplete type will have is that a call or body will be permitted on a subprogram with tagged incomplete parameters, provided they are not controlling parameters. Tagged or untagged incomplete types will be permitted as both parameters and results when declaring a subprogram.
The net effect of this proposal is that changing a "with" to a "limited with" will be much less of a disruption for a client package, since it may continue to declare subprograms using the types from the limited-with'ed package. It won't be able to use those types as component types, but access types are frequently an adequate work-around in that case.
!example
!corrigendum 3.10.1(8/2)
Replace the paragraph:
by:
!corrigendum 3.10.1(8.2/2)
Replace the paragraph:
by:
!corrigendum 3.10.1(9.1/2)
Delete the paragraph:
If such a name occurs within the declaration list containing the completion of the incomplete view, it may also be used:
!corrigendum 3.10.1(9.2/2)
Delete the paragraph:
!corrigendum 3.10.1(10/2)
Replace the paragraph:
A prefix that denotes an object shall not be of an incomplete view.
by:
A prefix that denotes an object shall not be of an incomplete view. An actual parameter in a call shall not be of an untagged incomplete view. The result object of a function call shall not be of an incomplete view. A prefix shall not denote a subprogram having a formal parameter of an untagged incomplete view, nor a return type that is an incomplete view.
!corrigendum 3.10.1(13/2)
Insert after the paragraph:
85 Within a declarative_part, an incomplete_type_declaration and a corresponding full_type_declaration cannot be separated by an intervening body. This is because a type has to be completely defined before it is frozen, and a body freezes all types declared prior to it in the same declarative_part (see 13.14).
the new paragraph:
86 A name that denotes an object of an incomplete view is defined to be of a limited type. Hence, the target of an assignment statement shall not be of an incomplete view.
!ACATS test
Add ACATS tests for this new feature.
!appendix

From: Tucker Taft
Sent: Saturday, June 6, 2009  3:58 PM

Here is an AI that came out of discussions about access types we have been
having over the past couple of months.  Basically it allows incomplete types as
parameter and result types, so long as at the point of call or the body the
types are fully defined.

This makes changing a "with" clause to a "limited with"
clause *much* less disruptive, since there is no need to change the
parameter/result profile of any subprograms declared in the client package just
because the types might be incomplete because they are coming from a limited
view of a package.

[This is version /03 of the AI, the earlier versions were merged into AI05-149 and eliminated here. - ED]

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

From: Bob Duff
Sent: Saturday, June 6, 2009  4:30 PM

> Here is an AI that came out of discussions about access types we have
> been having over the past couple of months.  Basically it allows
> incomplete types as parameter and result types, so long as at the
> point of call or the body the types are fully defined.

Seems like a big improvement to the language.  Ideally, access type should be
used only when you really want reference semantics.  This change moves closer to
that ideal.

> This proposal originally focused on a concern that a "limited with"
> naming a package with named access types forces the use of a lot of
> explicit conversion and/or anonymous access types in the clients.  We
> originally proposed to allow "incomplete access types" to be used as
> formal parameters and result types, to avoid the need for all of the
> conversion.  However, after analysis of the issues involved, it became
> clear that it was possible to generalize, and in some ways simplify,
> the proposal by allowing the use of *any* limited type as a parameter
> or
                                        ^^^^^^^ I think you mean "incomplete
                                       type from a limited-with'ed package".

[Corrected in the posted version /03, Editor.]

> result type, provided that the full definition was available at the
> point of call or at the definition of the body of the subprogram.
>
> An incomplete type is OK as a parameter or result since, until there
> is a call, there is no need to know the representation of the type.
> This is in contrast to the case with components, where an aspect
> clause would need to be obeyed to ensure that streaming, aliased
> objects, etc., work as expected.
>
> Currently compilers generally do know the representation of the
> parameters and result at the point of declaration of a subprogram
> (though not for access-to-subprogram declarations).

What's the acc-to-subp case you're referring to?

>... However, it should
> be possible to handle the lack of such representation information by
>having the compiler implicitly create a local access-to-subprogram type
>at the point of call, and then call through that, using only the
>address  of the subprogram with incomplete types in its declaration,
>while determining  the parameter passing mechanism from the access-to-subprogram type.
>
> Note that we have chosen to allow incomplete types as function
> results, even though we restricted tagged incomplete types to being
> parameters only.  This seems inconsistent.  Why should tagged
> incomplete types be
> *more* restrictive than incomplete types in general? Well, they
> shouldn't be, so with this proposal, the only advantage a tagged
> incomplete type will have is that a call or body *will* be permitted
> on a subprogram with tagged incomplete parameters, provided they are
> not controlling parameters.  Tagged or untagged incomplete types will
> be permitted as both parameters and results when declaring a subprogram.
>
> The net effect of this proposal is that changing a "with" to a "limited with"
> will be much less of a disruption for a client package, since it may
> continue to declare subprograms using the types from the limited-with'ed package.
> It won't be able to use those types as component types, but access
> types are frequently an adequate work-around in that case.

That seems like a secondary benefit.  The primary benefit is that when you use
"limited with" (in the first place) you don't have to use pointers when you
don't want pointer semantics.  I'd say that first, then ``In addition, changing
a "with" to a "limited with"...''.

> Generic Formal Incomplete Types?
>
> I wonder whether we could have generic formal incomplete types as a
> way to allow instantiation with a private type before it is completely
> defined.  This might be sufficient for a "signature"
> generic.

Interesting idea.

Does the "use package Blah" thing provide a different way to do signature
generics?

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

From: Tucker Taft
Sent: Sunday, June 7, 2009  6:15 AM

> ...  However, after analysis of the issues involved, it became
>> clear that it was possible to generalize, and in some ways simplify,
>> the proposal by allowing the use of *any* limited type as a parameter
>> or
>                                         ^^^^^^^ I think you mean
> "incomplete type from a limited-with'ed package".

Right you are.

 > ...
>> Currently compilers generally do know the representation of the
>> parameters and result at the point of declaration of a subprogram
>> (though not for access-to-subprogram declarations).
>
> What's the acc-to-subp case you're referring to?

You are allowed to use incomplete types as parameter or result types in an
access-to-subprogram type declaration.

> ...
>> Generic Formal Incomplete Types?
>>
>> I wonder whether we could have generic formal incomplete types as a
>> way to allow instantiation with a private type before it is
>> completely defined.  This might be sufficient for a "signature"
>> generic.
>
> Interesting idea.
>
> Does the "use package Blah" thing provide a different way to do
> signature generics?

Yes, by putting most of the content of a (generic) package into an "integrated"
subpackage, you can then follow the integrated subpackage with one or more
generic instantiations, which are allowed to use private types defined in the
integrated subpackage.

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

From: Tucker Taft
Sent: Saturday, June 6, 2009  3:24 PM

I'm trying to figure out what is currently allowed for subprograms with
parameters of a tagged incomplete type.  Calling a subprogram freezes its
profile, and freezing its profile freezes all of its parameter types.  What
happens when you freeze a tagged incomplete type?  Isn't that illegal if the
type isn't completely defined?

Are incomplete types produced by a limited view of a package "completely
defined" everywhere, so that freezing them is OK?  I presume that freezing an
incomplete type that is defined by an incomplete type declaration is illegal if
it happens in a place outside the scope of the full definition.

I am going to proceed in my work on AI05-0151 presuming that it is OK to freeze
an incomplete type coming from the limited view of a package, and it has no
effect, while freezing an incomplete type defined by an incomplete type
declaration would be illegal outside the scope of the full type definition.

I suspect this question needs a more explicit answer somewhere in the RM, or at
least in the AARM.

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

From: Bob Duff
Sent: Saturday, June 6, 2009  4:33 PM

...
> I suspect this question needs a more explicit answer somewhere in the
> RM, or at least in the AARM.

I'm puzzled by this message.  The version of AI05-0151-1v3 you just sent says
you can't call a subp or give its body, until you have completion. Isn't that
obviously necessary?

Maybe if you gave an example of what you're asking, as in "Should the following
be legal?"...

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

From: Randy Brukardt
Sent: Saturday, June 6, 2009  9:56 PM

> I'm trying to figure out what is currently allowed for subprograms
> with parameters of a tagged incomplete type.
> Calling a subprogram freezes its profile, and freezing its profile
> freezes all of its parameter types.  What happens when you freeze a
> tagged incomplete type?  Isn't that illegal if the type isn't
> completely defined?

13.14(17): "A type shall be fully defined before it is frozen." So, yes, of
course, that is illegal.

> Are incomplete types produced by a limited view of a package
> "completely defined" everywhere, so that freezing them is OK?
>  I presume that freezing an incomplete type that is defined by an
> incomplete type declaration is illegal if it happens in a place
> outside the scope of the full definition.

I don't think this matters; either the completion exists (in which case it is
fine to freeze it elsewhere) or it does not.

I surely would expect that all entities imported by with clauses are considered
frozen. That doesn't appear to be an explicit rules, but it is true because the
exported entities are all frozen by the end of the spec. Since all views are
frozen at once, that surely must include any exported incomplete views in the
limited view of the package. QED. :-)

And in this case, Robert's rule of absurdity would apply: if tagged limited
views imported by with clauses were *not* frozen, it would be impossible to use
them in subprogram parameters. Which would make all of the effort to define that
moot. That's an absurd result.

The AARM notes added by AI05-0017-1 (13.14(3.b-3.b.1/3)) sort of address this
topic. but don't explicitly mention limited views. Probably we ought to add an
AARM note to mention this meta-rule (probably in the Language Design
Principles).

Unrelated aside: 13.14(1.j) is misleading, as all of these entities have
freezing and get frozen at particular points (for Convention and address clauses
at least); I think the point of the note is that we don't use freezing per-se to
handle most issues of premature access. Probably ought to be rewritten.

> I am going to proceed in my work on AI05-0151 presuming that it is OK
> to freeze an incomplete type coming from the limited view of a
> package, and it has no effect, while freezing an incomplete type
> defined by an incomplete type declaration would be illegal outside the
> scope of the full type definition.

That would be correct.

> I suspect this question needs a more explicit answer somewhere in the
> RM, or at least in the AARM.

I think an AARM note is enough, since it clearly (!) follows from the existing
freezing rules. But I would agree that it isn't obvious.

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

From: Tucker Taft
Sent: Sunday, June 7, 2009  6:21 AM

...
> I'm puzzled by this message.  The version of AI05-0151-1v3 you just
> sent says you can't call a subp or give its body, until you have completion.
> Isn't that obviously necessary?

The issue is with the *current* rules that allow the use of tagged incomplete
types as parameters. Can these be incomplete at the point of call or the body,
provided they came from the limited view of a package?

> Maybe if you gave an example of what you're asking, as in "Should the
> following be legal?"...

OK:

     package P is
        type T is tagged null record;
     end P;

     limited with P;
     package Q is
        procedure M(X : P.T);
        type Acc is access T;
     end Q;

     -- NOTE: no "with" of P here
     package body Q is
        procedure M(X : P.T) is ... -- legal?

        Y : Acc;

     begin
        M(Y.all);  -- legal?
     end Q;

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

From: Bob Duff
Sent: Sunday, June 7, 2009  8:12 AM

OK, I see what you're getting at.

Both of the above had better be illegal, right?
Y has to be null, but we plugged a hole like that in Ada 83.

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

From: Tucker Taft
Sent: Sunday, June 7, 2009  8:29 AM

> Both of the above had better be illegal, right?

No, I think our intent was that both of the above would be *legal*, since we
know that tagged types are passed by reference, and so there is no problem
passing them around even if you don't know anything about them.

> Y has to be null, but we plugged a hole like that in Ada 83.

I should have thrown in some "..." since my presumption was that Y might have
been initialized by calling some function that returned an Acc.  That function
would presumably be in another package which *does* have a non-limited "with" of
P, and can legally do an allocator to create a non-null Acc value.

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

From: Randy Brukardt
Sent: Sunday, June 7, 2009  9:38 PM

> > Both of the above had better be illegal, right?
>
> No, I think our intent was that both of the above would be *legal*,
> since we know that tagged types are passed by reference, and so there
> is no problem passing them around even if you don't know anything
> about them.

That is my understanding as well. That is why 3.10(10/2) talks about *prefixes*
that are of incomplete views, as opposed to *names* that are of incomplete
views. The call cannot be a dispatching call (since we don't know where the tag
is), but a simple "pass-through" call is allowed.

OTOH, we can't support that for untagged types (because we don't know how
they're passed) or for function results (since they are creating a new object,
even for tagged types). So it seems that Tucker cannot rely solely on the
freezing rules to implement the completeness check here.

(That appears to be the difference between tagged and untagged incomplete types
in this scheme, along with the use of 'Class: that you can declare bodies and
make calls with tagged incomplete parameters/objects, but not with untagged
incomplete.)

> > Y has to be null, but we plugged a hole like that in Ada 83.
>
> I should have thrown in some "..." since my presumption was that Y
> might have been initialized by calling some function that returned an
> Acc.  That function would presumably be in another package which
> *does* have a non-limited "with" of P, and can legally do an allocator
> to create a non-null Acc value.

Right, that was the idea. If a package is just passing a tagged object from one
package to another, there is no need to know any details about the type, and, as
Bob mentioned in another message, we don't want to force using access types
unless the reference semantics are actually needed.

I'm not sure this really works very well in practice, but it surely was intended
to be possible.

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

From: Tucker Taft
Sent: Tuesday, November 3, 2009  10:24 AM

Here is the AI allowing incomplete types within a profile for a subprogram/entry
declaration, provided the full type is visible at the point of the body and at
each call.

[This is version /04 of the AI - ED.]

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

From: Randy Brukardt
Sent: Friday, December 11, 2009  8:31 PM

The wording of this AI has:

[Redundant: A name that denotes an object of an incomplete view is defined to be
of a limited type. Hence, the target of an assignment statement shall not be of
an incomplete view.]

as a new inserted paragraph. This seems unnecessary to me (esp. in normative
wording), given that two other places mention that incomplete views are limited
(3.10.1(2.1/2) and the newly inserted 7.6(6.1/3) (from AI05-178, which I
coincidentally just read - it also was approved in St. Pete)). Any Ada reader
that needs to be told what "limited" means is rather behind the curve. :-)

So I suggest that this paragraph either be made into a user note (and inserted
after 3.10.1(13)) or dropped altogether. Any preference which?

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

From: Randy Brukardt
Sent: Friday, December 11, 2009  11:08 PM

I was finished with this AI when I remembered that I've already done test
objectives for 3.10.1, and that I needed to update them.

Unfortunately, that caused me to find out that Tucker's simplified wording is
just plain wrong. (Update: well, maybe not. :-)

Tucker replaced the following three paragraphs:

  If such a name occurs within the declaration list containing the
  completion of the incomplete view, it may also be used:

    * as the subtype_mark defining the subtype of a parameter or result
    of an access_to_subprogram_definition or an access_definition for an
    access-to-subprogram type.

  If any of the above uses occurs as part of the declaration of a
  primitive subprogram of the incomplete view, and the declaration occurs
  immediately within the private part of a package, then the completion of
  the incomplete view shall also occur immediately within the private
  part; it shall not be deferred to the package body.

with one:

  If any of the above uses occurs as part of the declaration of a
  primitive subprogram of the incomplete view, or as part of an
  access_to_subprogram_definition or an access_definition for an
  access-to-subprogram type, then the primitive subprogram declaration
  or the access-to-subprogram type definition shall occur within the
  declaration list immediately containing the completion of
  the incomplete view.

The deletion of the first two paragraphs was done because it is obvious that the
first two paragraphs rules are subsumed by the permission to use these in any
profile in a declaration. Tucker moved the restriction to the third paragraph.

However, the third paragraph was written only for *incomplete types*; a
subprogram cannot be primitive for an imported type. But the wording as written
actually makes it illegal to use an incomplete view in an access-to-subprogram
type, as the completion is not *immediately contained* in the same declaration
list.

It seems very odd to allow incomplete views anywhere in regular subprograms but
not in access-to-subprograms. The old rule gave *additional* permissions to use
incomplete types in access-to-subprograms that were not allowed ever in regular
subprograms. The proposed rules invert the situation. I have to think this is a
mistake.

The obvious fix is to note that it only applies when the incomplete view is
declared in the same declaration list as the primitive subprogram or
access-to-subprogram type.

But I am wondering if we need the rule at all for access-to-subprogram types. I
suspect the purpose was to prevent calls when the type isn't complete. But we
now have a rule specifically against that. The reason that we felt OK to remove
some of these restrictions was the fact that you already had to be able to do it
for some access-to-subprogram types.

Update: I just went and read the !discussion of AI95-00326, which introduced
incomplete views and tagged incomplete types. This says that the reason that the
rule 3.10.1(9.1-2/2) was introduced was to allow dereferences that are whole
incomplete objects (essentially to allow the "prefix" rule of 3.10.1(10/2), and
to disallow calls using those dereferences. We now do that explicitly, so there
doesn't seem to be any further reason for the restriction.

With this explanation in hand, we ought to consider either leaving 3.10.1(9.3/2)
alone, or just changing as Tucker had previously done.

However, if we do that, we need to consider the effect on 'Access. If an
implementation needs to make a wrapper at the point of 'Access, that could be
impossible to do if the completion is never seen in the same compilation unit.

For instance:

   package Some is
       type T ....
   end Some;

   limited with Some;
   package Other then
       procedure Oper (P : Some.T); -- Legal by AI05-0151.
       type Acc_Single is access procedure (P : Some.T); -- (1)

       P : Acc_Single := Oper'Access; -- (2)
   end Other;

(1) is illegal by the wording that Tucker proposed. But the explicit reason for
that illegality isn't needed anymore, so perhaps we ought to make it legal. But
then (2) would be legal. But that might be a problem if a compiler needed some
sort of wrapper to implement 'Access, as it will never know how to pass T while
compiling this spec. (The Ada language explicitly allows this to be a wrapper,
as it does not require two uses of 'Access to produce an equal result.) It would
know the details by the point of a call, but then how would it tell what the
original routine was? (Janus/Ada uses this wrapper model in a few cases.)

One possibility would be to treat 'Access like a call vis-a-vis incomplete rules
(completions need to have been seen or in the same declaration list). (2) in the
example above might have to be moved to the body elaboration, but that wouldn't
be that hard; and you can't do it at all currently, so we'd be adding
functionality.

Alternatively, we might prefer to keep this restriction, although for other
reasons.

Either way, we need to explain that in the AI, and we need to consider this case
explicitly. So I reluctantly call to reopen this AI.

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

From: Tucker Taft
Sent: Saturday, December 12, 2009  8:57 AM

(Reference note vs. dropping of new text.)

Probably dropping is fine.  No one in their right mind would expect to be able
to assign to an incomplete view, especially now that we have finally made it
illegal... ;-)

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

From: Tucker Taft
Sent: Saturday, December 12, 2009  9:07 AM

Yes, it sounds like we should re-open it.

I am not feeling clever enough this morning to follow all of your logic, but I
do see the basic problem that we aren't allowing you to define an
access-to-subprogram type that uses an incomplete type from a limited view of a
package.  That does seem weird, if you can write normal subprogram declarations
using those types, but it may be a necessary restriction.  In any case it does
seem to need more thought...

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

From: Randy Brukardt
Sent: Saturday, December 12, 2009  4:53 PM

My logic was pretty twisted because I kept changing my mind. But while brushing
my teeth this morning, I realized that the rules that you gave are incompatible
with Ada 2005. That surely isn't intended, so more work is definitely needed.
(And I already finished the work of adding this wording to the Standard -
grumble.)

Here's the problem:

   package OO is
      type T is tagged ...
   end OO;

   limited with OO;
   package PP is
      type Singleton is access procedure (P : OO.T); -- (3)
   end PP;

(3) is legal in Ada 2005, as OO.T is a tagged incomplete view, and the use of it
is in a formal part (3.10.1(8.2/2)).

However, (3) is illegal given the proposed rules in Ada 2012. 3.10.1(8.2/2) now
only refers to bodies, which this declaration is not. The newly added rule
3.10.1(8.1/3) would allow it, but then the exception 3.10.1(9.3/3) "If any of
the above uses" would apply, as this is an access_to_subprogram_declaration. And
the exception requires the completion to be in the same declarative list, which
is never the case for limited with, so this is illegal.

There wasn't any intent for the legality to change here (even if we wanted to
keep untagged uses illegal, which is not certain), so we have a problem. Back to
the drawing board.

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

From phone meeting #6 (21-Jan-2010):

Revise wording to allow the same incomplete types from limited views in
access-to-subprogram. Require completions at/before the use of 'Access for
untagged incomplete types in access-to-subprogram types - treat similarly
to a call).

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


Questions? Ask the ACAA Technical Agent