!standard 3.4(18/3) 11-02-07 AI05-0240-1/01 !standard 3.10.1(8/3) !standard 3.10.2(13.1/2) !class presentation 11-02-04 !status Amendment 2012 11-02-04 !status work item 11-02-04 !status received 10-09-16 !priority Medium !difficulty Easy !subject Rewordings from First Editorial Review !summary Change wording of existing approved AIs as suggested by various ARG members during the first editorial review of the draft standard. !question Some of the new wording in the standard is unnecessarily confusing. Should we improve it? (Yes.) !recommendation (See Summary.) !wording Change the first sentence of 3.4(18/3) [as modified by AI05-0164-1] to: The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent or progenitor type, other than those subtypes found in the designated profile of an access_definition, with a corresponding subtype of the derived type. ... Modify 3.10.1(8/3) [as modified by AI05-0151-1]: * as the subtype_mark in an access_definition {for an access-to-object type}; Modify 3.10.1(13.2/3) [as added by AI05-0148-1]: * The accessibility level of the type of a stand-alone object of an anonymous access-to-object type is the same as the accessibility level of the type of the access value most recently assigned to the object[, but]{; [Redundant: accessibility checks ensure that this} is never deeper than that of the declaration of the stand-alone object{]}. Modify 3.10.1(13.3/3) [as added by AI05-0142-4]: The accessibility level of an explicitly aliased (see 6.1) formal parameter in a function body is determined by the point of call [(which] {; it} is the same level that the return object ultimately will have[)]. Modify 5.4(6/3) [as modified by AI05-0188-1]: The possible values of the selecting_expression shall be covered {(see 3.8.1)} as follows: AARM discussion: The meaning of "covered" here and in the following rules is that of the term "cover a value" that is defined in 3.8.1. Modify 6.2(11) [because of AI05-0142-4]: For {other} parameters [of other types], it is unspecified whether the parameter is passed by copy or by reference. Modify 6.2(12) [because of AI05-0142-4]: If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified {and is not an explicitly aliased parameter}, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct). !discussion These wording changes seem to be an improvement in readability and understandability, but are not intended to change the meaning of the words. !corrigendum 3.4(18/3) @drepl The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1), other than those found in the designated profile of an @fa, that is of the parent or progenitor type with a @i of the derived type. For a given subtype of the parent or progenitor type, the corresponding subtype of the derived type is defined as follows: @dby The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent or progenitor type, other than those subtypes found in the designated profile of an @fa, with a @i of the derived type. For a given subtype of the parent or progenitor type, the corresponding subtype of the derived type is defined as follows: !corrigendum 3.10.1(8/3) @drepl @xbullet in an @fa;> @dby @xbullet in an @fa for an access-to-object type;> !corrigendum 3.10.2(13.1/3) @dinsa @xbullet @dinss @xbullet @xbullet !corrigendum 5.4(6) @drepl The possible values of the @fa shall be covered as follows: @dby The possible values of the @i@fa shall be covered (see 3.8.1) as follows: !corrigendum 6.2(11) @drepl For parameters of other types, it is unspecified whether the parameter is passed by copy or by reference. @dby For other parameters, it is unspecified whether the parameter is passed by copy or by reference. !corrigendum 6.2(12) @drepl If one @fa denotes a part of a formal parameter, and a second @fa denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two @fa are considered @i. If an object is of a type for which the parameter passing mechanism is not specified, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct). @dby If one @fa denotes a part of a formal parameter, and a second @fa denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two @fa are considered @i. If an object is of a type for which the parameter passing mechanism is not specified and is not an explicitly aliased parameter, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct). !ACATS test No additional tests should be needed; the original AIs outline any needed tests. !appendix [Editor's note: These mails are organized by section of change, rather than by the date.] From: Tucker Taft Sent: Tuesday, September 21, 2010 2:44 PM The first sentence of paragraph 3.4(18/3) is a doozy: The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1), other than those found in the designated profile of an access_definition, that is of the parent or progenitor type with a corresponding subtype of the derived type. ... Perhaps it might be slightly easier if the "that is of the parent or progenitor type" part were moved earlier and the word "subtypes" is added: The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent or progenitor type, other than those subtypes found in the designated profile of an access_definition, with a corresponding subtype of the derived type. ... **************************************************************** From: Tucker Taft Sent: Tuesday, September 21, 2010 3:29 PM Paragraph 3.10.1(8/3) might be clearer with the following change: * as the subtype_mark in an access_definition {for an access-to-object type}; **************************************************************** From: Tucker Taft Sent: Sunday, October 17, 2010 11:42 PM These two paragraphs seem problematic. I suggest the following minor edits: 13.2/3 The accessibility level of the type of a stand-alone object of an anonymous access-to-object type is the same as the accessibility level of the type of the access value most recently assigned to the object[, but]{; [Redundant: accessibility checks ensure that this} is never deeper than that of the declaration of the stand-alone object{]}. 13.3/3 The accessibility level of an explicitly aliased (see 6.1) formal parameter in a function body is determined by the point of call [(which] {; it} is the same level that the return object ultimately will have[)]. **************************************************************** From: Steve Baird Sent: Friday, October 15, 2010 5:33 PM In 5.4 (case statements), it seems that we never really define what choices are covered by an "others" choice. I think it has been this way for years. Is this a problem? Note that there is a legitimate question here about whether an others clause covers values outside of the "covered" subtype (i.e., the subtype defined in 7/3 - 9). ==== Noting the obvious, 5.5.1 (User-Defined Iterators) is not there yet. ==== The wording for exit statements and for goto statements is nonuniform. For gotos, we get "The execution of a goto_statement transfers control to the target statement, completing the execution of any compound_statement that encloses the goto_statement but does not enclose the target. For exit statements, there is no analogous "completing the execution of any component_statement that ,,," wording. There should be. ==== In 6.1's "extensions to Ada 2005" section, we've got Parameters can now be explicitly aliased, allowing returning of values and forcing by-reference parameter passing. "Allowing returning of values"? Well if we couldn't do that before, I suppose it is a good thing that we can do that now. I think this was supposed to be seomthing like "allowing function result parts to designate parameters" ==== 6.2(12) If a( object is of a type for which the parameter passing mechanism is not specified, ... With the introduction of aliased parameters, we don't want this test to be based on the type of the parameter. This should not apply, for example, to an aliased parameter of type Integer. Strictly speaking, the same applies to For parameters of other types, it is unspecified whether the parameter is passed by copy or by reference. ===== In 6.3, the statement A subprogram_body is considered a declaration. seems odd. Probably not enough of a problem here to justify changing well-established wording. But it is odd. ==== In 6.4's Name Resolution Rules section, we see This rule is an overloading rule (see 8.6). Any rule that occurs in a Name Resolution Rules section is an overloading rule. Is this a helpful (albeit redundant) clarification, or a harmful suggestion that perhaps this statement is actually necessary for some reason. How about leaving the statement in, but flagging it as redundant? ==== The 6.4.1 rules for rejecting calls with evaluation order dependencies seem like a lot of complication for very little benefit, but we've already had that discussion. ==== 6.5 Can an extended return statement declare a return object of an abstract type? function F return T'Class is begin return X : Abstract_Extension_Of_T := A_E_O_T (Y); If that's supposed to be illegal, what rule enforces that? ==== 6.7: We want to disallow pre- and post-conditions on null procedures, right? Otherwise, we have problems with the "just pick one, it doesn't matter which" model that is used when we inherit multiple null procedures from multiple progenitors. Is this properly enforced? ==== 7.3(1.a): A private (untagged) type can be thought of as a record type with the type of its single (hidden) component being the full view. Add "undiscriminated", as in A private (untagged and undiscriminated) private type can ... ? Is this too pedantic? Similarly, 1.b doesn't mention classwide streaming operations: A private tagged type can be thought of as a private extension of an anonymous parent with no components. The only dispatching operation of the parent is equality (although the Size attribute, and, if nonlimited, assignment are allowed, and those will presumably be implemented in terms of dispatching). Should it? ==== 7.3(7) refers to "derivatives", as in "no derivatives of the partial view are allowed" This term is never really defined (see 3.4, which simply introduces the term by using it). Do we care? Would a glossary entry be appropriate? ==== 7.4(6/3). interactions between deferred constants and predicates need to be worked out. ==== 7.6(17.1/3) says: When a function call or aggregate is used to initialize an object, . ... Under certain circumstances, the anonymous object is required to be built in place, What about when a parentheisized expression, qualified expression, or conditional expression is used to initialize an object? ==== If the entire "Implementation Requirements" section of 7.6 has been deleted, then shuld the two-word section heading (i.e., "Implementation Requirements") also be deleted? ===== Chapter 8 looks fine. There would have been more to chew on here if we were dealing with integrated packages. **************************************************************** From: Bob Duff Sent: Friday, October 15, 2010 6:09 PM > In 5.4 (case statements), it seems that we never really define what > choices are covered by an "others" choice. I think it has been this > way for years. I think we should focus on "new bugs". Two kinds: The new feature wording has bugs. Regressions: The new feature wording causes bugs in old features. I think we should ignore old bugs in old features. In this particular case, I think it's covered by (pun!) 3.8.1 (variant parts): 12.a Ramification: For case_statements, this includes values outside the range of the static subtype (if any) to be covered by the choices. It even includes values outside the base range of the case expression's type, since values of numeric types (and undefined values of any scalar type?) can be outside their base range. But even if that weren't the case, I don't think the RM review needs to go looking for old bugs in old features, unless some compiler writer is honestly confused about what to do, or some programmer is honestly confused about what to expect from compilers. > interactions between deferred constants and predicates need to be > worked out. Right. Please pester me about that until I get it done. ;-) - Bob P.S. Is anybody going to read the new RM cover to cover? I got "volunteered" for that last time 'round, and it was a HUGE job. But I did find some interesting problems. That's how "prefix views" got invented, at the last minute, if I recall correctly. I suppose this will be my job yet again, although I fear the RM has gone well beyond human comprehension this time. Sigh. **************************************************************** From: Randy Brukardt Sent: Friday, October 15, 2010 6:49 PM > > In 5.4 (case statements), it seems that we never really define what > > choices are covered by an "others" choice. I think it has been this > > way for years. > > I think we should focus on "new bugs". Two kinds: > > The new feature wording has bugs. > > Regressions: The new feature wording causes bugs in old features. > > I think we should ignore old bugs in old features. I agree for the most part. I am suggesting changing the wording of case statements slightly in order to make the wording for case expressions easier (the current case expression wording makes it really hard to determine which of the rules in 5.4 apply to case expressions - and not all of them do apply). The suggested change is to give "expression" a prefix so we don't have the say the clunky "expression of the case statement", especially as there are lots of expressions that make up the case statement. So I suppose we could fix any missing wording at the same time. (But you point out that the wording isn't missing, it's just in 3.8.1 will a lot of the other case statement rules -- the place no one thinks to look). ... > P.S. Is anybody going to read the new RM cover to cover? I got > "volunteered" for that last time 'round, and it was a HUGE job. > But I did find some interesting problems. That's how "prefix views" > got invented, at the last minute, if I recall correctly. > > I suppose this will be my job yet again, although I fear the RM has > gone well beyond human comprehension this time. Sigh. I wasn't planning to require anyone to read the entire thing; the point of this review was to get 90% of that done now, with the labor split up. We'll do another similar review at the last minute. But since you have volunteered to read the whole thing... :-) **************************************************************** From: Randy Brukardt Sent: Monday, February 7, 2011 10:07 PM [Note that there are questions and an assignment for an AI below.] ... > In 5.4 (case statements), it seems that we never really define what > choices are covered by an "others" choice. I think it has been this > way for years. Is this a problem? Note that there is a legitimate > question here about whether an others clause covers values outside of > the "covered" subtype (i.e., the subtype defined in 7/3 - 9). Bob explained that this is defined in 3.8.1. The problem here is that no one ever thinks to look in 3.8.1 for this information (I know *I* don't!). In particular, 5.4(6-10, 12) all depend on the definition of "covers a value" in 3.8.1. Indeed, I didn't realize until just now that 5.4(6-10) actually depends on a formal term; I always thought that they were informally defined. So I think the addition of a cross-reference to 3.8.1 in 5.4(6) would be helpful, even though it is not technically a forward reference. (This term is only used here, so it is not one that is immediately familiar to readers.) The AARM Note is needed only because looking for "covered" won't get you anywhere, and it took me a while to realize that "value" does indeed appear in this sentence (the two important words are a long ways apart). That is: The possible values of the expression shall be covered {(see 3.8.1)} as follows: AARM discussion: The meaning of "covered" here and in the following rules is that of the term "cover a value" that is defined in 3.8.1. ... > ==== > > The wording for exit statements and for goto statements is nonuniform. > > For gotos, we get > > "The execution of a goto_statement transfers control to the target > statement, completing the execution of any compound_statement > that > encloses the goto_statement but does not enclose the target. > > For exit statements, there is no analogous "completing the execution > of any component_statement that ,,," wording. There should be. I don't see this. It seems to me that the only reason that gotos mention compound_statements at all is to get a form of the word "complete" into the sentence. The rules in 7.6.1 for completion and transfer of control surely apply in both of these case. Also note that there is no such wording for return statements, either; they also depend on "transfer of control" to do the right thing. In any case, Bob's "nothing has changed here, we're not fixing old problems" surely applies here. ... > ==== > > 6.2(12) > If a( object is of a type for which the parameter passing mechanism > is > not specified, ... > > With the introduction of aliased parameters, we don't want this test > to be based on the type of the parameter. This should not apply, for > example, to an aliased parameter of type Integer. > > Strictly speaking, the same applies to > For parameters of other types, it is unspecified whether the > parameter > is passed by copy or by reference. This seems to be a real problem. The first paragraph (the second one you mention) is easy. I suggest: 6.2(11): For {other} parameters [of other types], it is unspecified whether the parameter is passed by copy or by reference. [Is this specific enough? The rules that specify parameters that have specified parameter passing are widely separated in 6.2(3/3) and 6.2(10/3).] The second one is tougher. Not all of the objects talked about there are parameters; for non-parameters the type is surely relevant. So the easiest solution is to use the same one we used in 6.2(3) and 6.2(10): exclude aliased parameters explicitly: 6.2(12): If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified {and is not an explicitly aliased parameter}, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct). > ===== > > In 6.3, the statement > A subprogram_body is considered a declaration. > seems odd. Probably not enough of a problem here to justify changing > well-established wording. > But it is odd. It's bizarre, to the point we already had an AI about it (AI-222). We decided not to change anything. > ==== > In 6.4's Name Resolution Rules section, we see > This rule is an overloading rule (see 8.6). > > Any rule that occurs in a Name Resolution Rules section is an > overloading rule. Is this a helpful (albeit redundant) clarification, > or a harmful suggestion that perhaps this statement is actually > necessary for some reason. > > How about leaving the statement in, but flagging it as redundant? Makes sense to me. I think it is leftover Ada 83 junk, more confusing than helpful. In any case, this is just an AARM change so I don't have to mention it beyond this reply. ... > ==== > > 6.5 > Can an extended return statement declare a return object of an > abstract type? > > function F return T'Class is > begin > return X : Abstract_Extension_Of_T := A_E_O_T (Y); > > If that's supposed to be illegal, what rule enforces that? 3.9.3(8/3) says: The type denoted by a return_subtype_indication (see 6.5) shall not be abstract. Looks like it's covered to me - by AI05-0203-1. Looks like Adam beat you to this question by a year. > ==== > > 6.7: > We want to disallow pre- and post-conditions on null procedures, > right? Otherwise, we have problems with the "just pick one, it doesn't > matter which" model that is used when we inherit multiple null > procedures from multiple progenitors. > Is this properly enforced? AI05-0230-1 covered this. > ==== > > 7.3(1.a): > A private (untagged) type can be thought of as a record type with > the > type of its single (hidden) component being the full view. > > Add "undiscriminated", as in > A private (untagged and undiscriminated) private type can ... > ? > > Is this too pedantic? Yes, since defaulted discriminants work with this definition. And you *can think of* if it even when discriminated (it's just not quite legal, but the model still works). The only change I would make to this note is to get rid of it, since it conflicts with the "view" model that we now use heavily. And I can't imagine what help this "component model" is supposed to provide -- it still requiring thinking about hidden component(s) -- it doesn't matter if there are one or more such components. So far as I can tell it's meaningless; why confuse readers with it. > Similarly, 1.b doesn't mention classwide streaming operations: > > A private tagged type can be thought of as a private extension of > an > anonymous parent with no components. The only dispatching operation > of > the parent is equality (although the Size attribute, and, if > nonlimited, assignment are allowed, and those will presumably be > implemented in terms of dispatching). > > Should it? Again, I'm not sure what the point is. It seems more confusing than helpful, especially once the "pedantic" thoughts are applied. Perhaps Bob or Tuck can enlighten us. ==== > > 7.3(7) refers to "derivatives", as in > "no derivatives of the partial view are allowed" > > This term is never really defined (see 3.4, which simply introduces > the term by using it). Do we care? > > Would a glossary entry be appropriate? I'd say insuffienctly broken. Maybe an index entry, but even that is a stretch (it's pretty obvious what is being talked about). I'd probably just fix it if anybody cares enough ("derivatives of the partial view" => "derived types whose parent type is the partial view", same for the full view). But I won't do that unless someone indicates that they care. > ==== > > 7.4(6/3). > > interactions between deferred constants and predicates need to be > worked out. What are you thinking about? I'm not aware of any "interactions". > ==== > > 7.6(17.1/3) says: > When a function call or aggregate is used to initialize an object, > . > ... Under certain circumstances, the anonymous object is required > to > be built in place, > > What about when a parentheisized expression, qualified expression, or > conditional expression is used to initialize an object? I think we need a general fix for this, there are far too many rules where we have to add text about one or all of these things. I assign Steve Baird to create an AI to address this problem once and for all. > ==== > > If the entire "Implementation Requirements" section of 7.6 has been > deleted, then shuld the two-word section heading (i.e., > "Implementation Requirements") also be deleted? It says around because of the "deleted paragraph" notations; it would disappear if/when we remove those. In this case, since this was originally an inserted paragraph, we don't need the "deleted paragraph" notation, so I've turned that off. ****************************************************************