Version 1.4 of ai05s/ai05-0244-1.txt
!standard 4.3.2(5.1/3) 11-03-09 AI05-0244-1/02
!class binding interpretation 11-02-15
!status Amendment 2012 11-03-09
!status ARG Approved 6-0-2 11-02-20
!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
Ancestor expressions that are qualified, parenthesized, or
are conditional expressions are subject to the same rules that a
stand-alone expression is.
!question
4.3.2(5.1/3) [from AI05-0067-1] 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
Replace 4.3.2(5.1/3):
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.
with:
If the type of the ancestor_part is limited
and at least one component is needed in the
record_component_association_list, then the ancestor_part shall not
be:
- a call to a function with an unconstrained result subtype; nor
- a parenthesized or qualified expression whose operand
would violate this rule; nor
- a conditional_expression having at least one dependent_expression
that would violate this rule.
!discussion
This is obvious; parens or qualification should not affect the semantics
of an expression. Conditional expressions are intended to work as similarly
to parens as possible.
The rule is recursive, of course. It applies to parenthesized qualified expressions
and qualified conditional_expressions and any other combination.
!corrigendum 4.3.2(5)
!comment As this is an inserted paragraph, we have to use the original number to
!comment force a conflict with AI05-0067-1.
@drepl
If the @fa<ancestor_part> is a function call and the type of the @fa<ancestor_part> is
limited, then the @fa<ancestor_part> shall have a constrained nominal subtype
unless there are no components needed in the @fa<record_component_association_list>.
@dby
If the type of the @fa<ancestor_part> is limited and at least one component is
needed in the @fa<record_component_association_list>, then the ancestor part shall
not be:
@xbullet<a call to a function with an unconstrained result subtype; nor>
@xbullet<a parenthesized or qualified expression whose operand
ould violate this rule; nor>
@xbullet<a @fa<conditional_expression> having at least one @i<dependent_>@fa<expression>
that would violate this rule.>
!ACATS test
Add cases like these to the B-Test that checks this rule.
!ASIS
No ASIS impact.
!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.
****************************************************************
From: Steve Baird
Sent: Wednesday, February 16, 2011 1:06 PM
> If you could bring some wording for AI05-0244-1 to the meeting, it
> would be appreciated. It was your question originally; the AI is empty
> except for the question.
[Following was the wording in version /01 of this AI - Editor.]
====
For conditional expressions, do we want an exemption which allows "bad"
dependent expressions if they are statically unevaluated?
I'm thinking "no".
****************************************************************
From: Tucker Taft
Sent: Wednesday, February 16, 2011 1:06 PM
...
> If the type of the ancestor_part is limited and at least one component
> is needed in the record_component_association_list, then the ancestor
> part shall not be
> - a call to a function with an unconstrained result subtype; or
"or" => "nor"
> - a parenthesized or qualified expression whose operand would violate
> thie rule; or
"thie" => "this"; "or" => "nor"
> - a conditional expression having at least one dependent expression
> which would violate this rule.
>
> ====
>
> For conditional expressions, do we want an exemption which allows
> "bad" dependent expressions if they are statically unevaluated?
> I'm thinking "no".
I agree. This is more of a "structural" restriction, not a value-based one,
so making it be different for something that is statically unevaluated doesn't
really make sense.
****************************************************************
From: Bob Duff
Sent: Wednesday, February 16, 2011 1:36 PM
> For conditional expressions, do we want an exemption which allows
> "bad" dependent expressions if they are statically unevaluated?
> I'm thinking "no".
I agree with your "no".
****************************************************************
Questions? Ask the ACAA Technical Agent