!standard E.2.1(7/4) 19-03-06 AI12-0320-1/01 !standard E.2.1(7.1/4) !class binding interpretation 19-03-06 !status Amendment 1-2012 19-03-06 !status work item 19-03-06 !status received 19-03-05 !priority Low !difficulty Easy !qualifier Clarification !subject Changes from the RM review !summary Various wording changes are made to clarify the Standard. !question (1) E.2.1(7/4) is confusing: ... nor a type with a part that is of a task type or protected type with entry_declarations. This can be read two ways as shown by the parens below: ... nor a type with a part that is of a ((task type or protected type) with entry_declarations). or ... nor a type with a part that is of a ((task type) or (protected type with entry_declarations)). !recommendation (1) The original wording makes it clear that the second interpretation is intended. Adding more connector words only helps a tiny bit, so the recommendation is to change this into a list of sub-bullets (and we can include the following bullet in that rewrite as well). !wording Replace E.2.1(7/4-7.1/4) with: * it shall not contain a library-level declaration: * of an access type that designates a class-wide type; * of a type with a part that is of a task type; * of a type with a part that is of a protected type with entry_declarations; nor * that contains a name that denotes a type declared within a declared-pure package, if that type has a part that is of an access type; for the purposes of this rule, the parts considered include those of the full views of any private types or private extensions. [Editor's note: Put the AARM notes after the appropriate bullet.] !discussion !corrigendum E.2.1(7/4) @drepl @xbullets;> @dby @xbullet !corrigendum E.2.1(7.1/4) @drepl @xbullet @dby @xinbull @xinbull @xinbulls; nor> @xinbull !ASIS No ASIS effect. !ACATS test !appendix From: Randy Brukardt Written: Wednesday, March 06, 2019 6:45 PM Jeff's review includes: >E.2.1 (7/4) it shall not contain a library-level declaration of an access type >that designates a class-wide type, nor a type with a part that is of a task >type or {of a} protected type with entry_declarations; I've been removing those redundant "of a" when I can, I view it as just noise. Moreover, in this case, it would make a reading of "of a task type" or "of a protected type with entry_declarations" plausible (which is wrong!). If I was going to make any change here at all, I'd drop the "type" after "task", so it would read ("of a task or protected type with entry declarations". Ugh: after looking at the pre-change sentence, it's obvious that the "wrong" reading is actually the one intended. But then just adding "of a" doesn't seem to be enough -- it makes the intended wording plausible, but does little to make it clear. (The original wording had a comma which made it a lot clearer as to the intended grouping.) Since this wording is from the Corrigendum, we have to put it on the agenda in any case. ****************************************************************