Version 1.1 of ai05s/ai05-0244-1.txt
!standard 4.3.2(5.1/3) 11-02-15 AI05-0244-1/00
!class binding interpretation 11-02-15
!status work item 11-02-15
!status received 11-01-19
!priority Low
!difficulty Easy
!qualifier Omission
!subject Ancestor parts that are qualified or parenthesized
!summary
** TBD **
!question
4.3.2(5.1/3) says:
If the ancestor_part is a function call and the type of the
ancestor_part is limited, then the ancestor_part shall have a
constrained nominal subtype unless there are no components needed in
the record_component_association_list.
This rule was introduced because of the implementation difficulties associated
with the otherwise-legal case where a build-in-place function call would have to
allocate storage for unknown extension components.
This rule doesn't seem to handle parenthesized expressions, qualified
expressions, and conditional expressions. They can pose the same problem as
the original rule was intended to prevent:
(Parent_Type'(Function_Call) with Extension_Component => 123);
seems to be allowed, but it introduces all the same difficulties that the given
rule was intended to prevent.
Should this rule be changed? (Yes.)
!recommendation
(See Summary.)
!wording
** TBD **
!discussion
--!corrigendum 12.5.1(5/2)
!ACATS test
!appendix
From: Steve Baird
Sent: Wednesday, January 19, 2011 4:14 PM
4.3.2(5.1/3) says:
If the ancestor_part is a function call and the type of the
ancestor_part is limited, then the ancestor_part shall have a
constrained nominal subtype unless there are no components needed in
the record_component_association_list.
This rule was introduced because of the implementation difficulties associated
with the otherwise-legal case where a build-in-place function call would have to
allocate storage for unknown extension components.
Should this rule be modified to somehow deal with qualified expressions, parens,
and (thanks to Randy for pointing this one out) conditional expressions?
Something like
(Parent_Type'(Function_Call) with Extension_Component => 123);
seems to be allowed, but it introduces all the same difficulties that the given
rule was intended to prevent.
****************************************************************
From: Bob Duff
Sent: Wednesday, January 19, 2011 4:20 PM
> Should this rule be modified to somehow deal with qualified
> expressions, parens, and (thanks to Randy for pointing this one out)
> conditional expressions?
Yes.
Can't it be fixed by removing "the ancestor_part is a function call and"?
I mean, if it's an aggregate, the problem can't come up, right?
****************************************************************
From: Randy Brukardt
Sent: Wednesday, January 19, 2011 4:35 PM
I wondered that, too. But it doesn't work. The *problem* can't come up, but the
rule could be triggered, because an object or aggregate can have a *nominal*
subtype that is unconstrained (the object or aggregate would be constrained by
its initial value in that case, but that doesn't change the nominal subtype).
But we don't want the rule triggered for other than function calls.
****************************************************************
Questions? Ask the ACAA Technical Agent