!standard 4.3.2(5.1/3) 11-02-16 AI05-0244-1/01 !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 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; or - a parenthesized or qualified expression whose operand would violate thie rule; or - a conditional expression having at least one dependent expression which would violate this rule. !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. **************************************************************** 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". ****************************************************************