!standard 10.1.2(20/2) 07-10-08 AI05-0040-1/03 !class binding interpretation 07-03-27 !status Amendment 201Z 08-11-26 !status WG9 Approved 07-11-08 !status ARG Approved 10-0-0 07-06-03 !status work item 07-03-27 !status received 07-03-27 !priority Medium !difficulty Easy !qualifier Omission !subject Limited with clauses on descendants !summary A limited with clause may not name an ancestor. !question One of the submitted tests for limited with clauses includes the following example: limited with BA12010; -- ERROR: package BA12010.Pak1 is pragma Elaborate_Body; end BA12010.Pak1; It seems that this should be illegal, as it is useless at best, and similar cases are illegal. But none of the existing rules seem to cover it. 10.1.2(20/2) says that the limited_with_clause cannot be on the "explicit declaration of the named package"; BA12010.Pak1 is not the named package, so we're OK, this rule doesn't apply. 10.1.2(21/2) says that we can't be in the scope of a nonlimited_with_clause that mentions the same unit. There is no nonlimited_with_clause here (and surely the parent can't with itself). So again we're OK. 10.1.2(22/2) talks only about use clauses, and there are none here. That doesn't trigger anything. So it seems this is legal. But should it have been illegal? (Yes.) !recommendation (See Summary.) !wording Change the last sentence of 10.1.2(20/2) as follows: in the context_clause for the explicit declaration of the named library package {or any of its descendants}; !discussion We want cases like this to be illegal, so that we don't have cases where we revert to the limited view (as those caused all kinds of holes). !corrigendum 10.1.2(20/2) @drepl in the @fa for the explicit declaration of the named library package; @dby in the @fa for the explicit declaration of the named library package or any of its descendants; !ACATS test A B-Test containing a case like this should be added to the ACATS. !appendix From: Randy Brukardt Date: Monday, March 26, 2007 11:22 PM I'm working on ACATS tests for the above rules on limited with clauses (LWC). One of the submitted tests for these rules contains the following case: limited with BA12010; -- ERROR: package BA12010.Pak1 is pragma Elaborate_Body; end BA12010.Pak1; It seems that this should be illegal, but I don't think any of the rules apply to it. 10.1.2(20/2) says that the LWC cannot be on the "explicit declaration of the named package"; BA12010.Pak1 is not the named package, so we're OK. 10.1.2(21/2) says that we can't be in the scope of a NLWC that mentions the same unit. There is no NLWC here (and surely the parent can't with itself). A parent might act like a with clause, but certainly there is nothing explicit here: and this rule is written in terms of the NLWC syntax. So again we're OK. 10.1.2(22/2) talks only about use clauses, and there are none here. That doesn't trigger anything. So it seems this is legal. Should it have been illegal? (It can't possibly be of any value!) If so, I suppose we'd need a modification to 10.1.2(20/2): "In the context clause for the explicit declaration of a descendant of the named library unit." More work for me (in the form of an AI)?? (Presuming my analysis is correct, I'll have to leave this case out of the test; can't include cases until at least a BI is accepted by WG9.) **************************************************************** From: Pascal Leroy Date: Tuesday, March 27, 2007 3:09 AM > limited with BA12010; -- ERROR: > package BA12010.Pak1 is > pragma Elaborate_Body; > end BA12010.Pak1; > > It seems that this should be illegal, but I don't think any > of the rules apply to it. It should definitely be illegal. We put in place all sorts of rules to prevent the case where we would revert to the limited view, in part because we didn't want to answer nasty questions about visibility holes and the like. Apparently this case wasn't caught. > Should it have been illegal? (It can't possibly be of any > value!) If so, I suppose we'd need a modification to > 10.1.2(20/2): "In the context clause for the explicit > declaration of a descendant of the named library unit." Sounds good, especially given that it's exactly what my favorite compiler implements. ****************************************************************