Version 1.1 of ai05s/ai05-0232-1.txt

Unformatted version of ai05s/ai05-0232-1.txt version 1.1
Other versions for file ai05s/ai05-0232-1.txt

!standard 7.6(17.1/3)          10-10-25 AI05-0232-1/00
!class binding interpretation 10-10-25
!status work item 10-10-25
!status received 10-09-24
!priority Low
!difficulty Easy
!qualifier Omission
!subject Hole in AI05-0067-1
!summary
!question
Is the following call built-in-place?
type Interface_Type is limited interface;
Obj : Interface_Type'Class := Some_Function(...);
where Some_Function is declared as returning Interface_Type'Class. Interface_Type'Class is not immutably limited, since a type derived from Interface_Type could be limited or nonlimited (AARM 7.5(8.c)). This would seem to mean that it's unspecified whether this function call is built in place, since the rule in 7.6(17.2) refers to the (full) type of the object, not to the type determined by the tag of the function result.
But this doesn't seem desirable, since the function result could be of a limited type, and in that case we still want to have the result built in place, with no copying.
Is a fix needed? (Yes.)
!wording
!discussion
Probably functions returning limited interfaces ought to be built-in-place. But I'm not sure how to word that. (Can this happen for components of a result? For an aggregate? I don't think so...)
[Editor's comments: Note that I can't quite imagine how to chose the return convention of a function at runtime, so I think it is fine to require limited classwide interfaces to be built-in-place; they can only be used as if they are limited even if the actual type is non-limited, so the problems with real assignments don't come up.]
!ACATS Test
!topic Possible hole in AI05-0067?
!reference 7.6(17.1/3-17.4/3)
!from Adam Beneschan 10-09-24
!discussion
I've just now found a reason to look over the new build-in-place rules, and I've run into something that may be an important omission.
The new rules say that, for a function call used to initialize an object, the function call must be built in place if the object's type is immutably limited, but it's unspecified whether it's built in place in other cases.
What happens in this case?
type Interface_Type is limited interface;
Obj : Interface_Type'Class := Some_Function(...);
where Some_Function is declared as returning Interface_Type'Class. Interface_Type'Class is not immutably limited, since a type derived from Interface_Type could be limited or nonlimited (AARM 7.5(8.c)). This would seem to mean that it's unspecified whether this function call is built in place, since the rule in 7.6(17.2) refers to the (full) type of the object, not to the type determined by the tag of the function result.
But this doesn't seem desirable, since the function result could be of a limited type, and I'd think that in this case we still want to have the result built in place, with no copying.
Should 7.6(17.1-17.4) be modified to require build in place when an object type is the 'Class of a limited interface type? I don't think this would be harmful in cases where the function result is actually a nonlimited type (see the last sentence of AARM 7.6(17.o)), but maybe there are cases where it would be a problem. (An alternative would be to require implementations to build the result in place if the function result's tag identifies a limited type, and let them choose if it identifies a nonlimited type. But from my point of view, in our implementation, generating code to decide this at runtime isn't feasible.)
****************************************************************
Questions? Ask the ACAA Technical Agent