Version 1.3 of ai05s/ai05-0244-1.txt

Unformatted version of ai05s/ai05-0244-1.txt version 1.3
Other versions for file 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 10-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