!standard 4.1.6(4/3) 14-10-02 AI12-0104-1/02 !standard 4.1.6(17/3) !class presentation 14-05-13 !status Corrigendum 2015 14-07-23 !status WG9 Approved 14-10-20 !status ARG Approved 7-0-0 14-06-28 !status work item 14-05-13 !status received 14-05-07 !priority Low !difficulty Easy !qualifier Clarification !subject Overriding an aspect is undefined !summary A confusing sentence regarding changing aspects is replaced by a user note. !question 4.1.6(4/3) uses some terminology that's not defined: These aspects are inherited by descendants of T (including the class-wide type T'Class). The aspects shall not be overridden, but the functions they denote may be. There is no such thing as overriding an aspect. It's probable that this was intended informally, but then we have an informal use and a formal use of the same term in the same sentence (the formal use is implicit in this wording, but it surely is there). Should this be changed? (Yes.) !recommendation (See Summary.) !wording Modify 4.1.6(4/3): These aspects are inherited by descendants of @i (including the class-wide type @I'Class). [The aspects shall not be overridden, but the functions they denote may be.] Add after 4.1.6(7/3): AARM Reason: This rule allows the replacement of the implementation of an indexing function and the addition of a new indexing function for a derived type, but not the removal of an indexing function. This is necessary so that indexing can be used on objects of T'Class. So long as the tag of O is that of its nominal subtype, we do not want T'Class(O)(I) to mean something different than O(I). Thus we cannot allow a change in the function identified. As T'Class(O)(I) expands into a dispatching call, we need to ensure that there is a body for each such function -- but it is OK for that body to be changed from the original body (that's just normal dispatching). [Editor's note: I added this AARM note because the original mail thread saw some confusion over the reason for this rule. I'm not sure if there is a better way to describe that we don't want dynamically and statically tagged indexing doing different things when they both identify the same type.] Add after 4.1.6(17/3): Notes: 6 The Constant_Indexing and Variable_Indexing aspects cannot be redefined when inherited for a derived type, but the functions that they denote can be modified by overriding or overloading. !discussion The original text here is marked as redundant; the actual rule is given in 4.1.6(7/3). As such, it's obvious that this was intended to be explanatory text. But, as it's given in the normative rules, it's easy to wonder what it means formally. Moreover, as it is a forward reference, a reader may not realize that it isn't normative and try to figure out what rules it implies. By replacing it by a user note, we eliminate any confusion, and we can clarify the sentence so we're not mixing formal and informal uses of the same term. !corrigendum 4.1.6(4/3) @drepl These aspects are inherited by descendants of @i (including the class-wide type @I'Class). The aspects shall not be overridden, but the functions they denote may be. @dby These aspects are inherited by descendants of @i (including the class-wide type @I'Class). !corrigendum 4.1.6(17/3) @dinsa When a @fa is interpreted as a constant (or variable) indexing, it is equivalent to a call on a prefixed view of one of the functions named by the Constant_Indexing (or Variable_Indexing) aspect of the type of the @i@fa with the given @fa, and with the @i@fa as the @fa of the prefixed view. @dinst @xindent<@s9> !ASIS No changes needed. !ACATS test No test needed. !appendix From: Randy Brukardt Sent: Wednesday, May 7, 2014 12:20 PM Ed points out that 4.1.6(4/3) uses some terminology that's not defined: "These aspects are inherited by descendants of T (including the class-wide type T'Class). The aspects shall not be overridden, but the functions they denote may be." There is no such thing as overriding an aspect. The second sentence here is intended to be an explanation of the intent of following rules, and is marked as "redundant" in the AARM. Still, we probably ought to use a different word than "overridden", which appears to have a technical meaning when it does not. I think "replaced" or "redefined" would be better. If it's confusing Ed, what chance do ordinary readers have? "The aspects shall not be {redefined}[overridden], but the functions they denote may be {overridden}." In the absence of objections, I'll just put this into the presentation AI. **************************************************************** From: Bob Duff Sent: Wednesday, May 7, 2014 12:53 PM > In the absence of objections, I'll just put this into the presentation AI. I think I object. I think "overridden" (in it's plain English, not-defined-by-RM sense) is clearer than "redefined". And even if that weren't so, it seems like a gratuitous change. I guess I'd like to hear from Ed what the real confusion is. I mean, are there two possible interpretations of that rule, such that different compilers might behave differently? Example? If not, then "If it ain't broke, don't fix it, and don't even spend time talking about fixing it!" ;-) **************************************************************** From: Ed Schonberg Sent: Wednesday, May 7, 2014 1:01 PM I was trying to understand the exact rule for inheritance of indexing aspects for derived container types, and I found that statement curious, because it says that you are not allowed to write the aspect but can still change its meaning by overriding the named subprogram. Excuse my density if I found that less than obvious. Overriding has otherwise a precise meaning, so i wanted to know if there was some indication of what it means for an aspect, but no such luck. That’s why I asked. **************************************************************** From: Bob Duff Sent: Wednesday, May 7, 2014 2:02 PM To me, it seems clear from the words that if T has "with Constant_Indexing => Mumble", then types derived from T cannot have "with Constant_Indexing => ...", but you can override Mumble. You went one step further to wonder what the rationale for that rule is, and I agree with you there, it's kind of curious. It's also curious that the sentence is in [...], meaning it's implied by other rules -- I wonder what those rules are. I suggest a compromise: AARM annotations, giving an example, and the rationale (if anybody remembers the rationale), and which rules imply it (if anybody knows). I still don't think changing the informal use of "overridden" to "redefined" is an improvement. I'd be inclined to think it's forbidding: type T is ... with Constant_Indexing => This, with Constant_Indexing => That; -- redefined from This to That. which is forbidden by other rules, and it's not the point of this rule. **************************************************************** From: Ed Schonberg Sent: Wednesday, May 7, 2014 2:13 PM > You went one step further to wonder what the rationale for that rule > is, and I agree with you there, it's kind of curious. > It's also curious that the sentence is in [...], meaning it's implied > by other rules -- I wonder what those rules are. The rationale is buried in the discussion section of AI05-0139, and has to do with iterations over a class-wide object initialized with a derived container. Would be helpful if that was in the AARM. **************************************************************** From: Randy Brukardt Sent: Wednesday, May 7, 2014 2:27 PM > I was trying to understand the exact rule for inheritance of indexing > aspects for derived container types, and I found that statement > curious, because it says that you are not allowed to write the aspect > but can still change its meaning by overriding the named subprogram. > Excuse my density if I found that less than obvious. > Overriding has otherwise a precise meaning, so i wanted to know if > there was some indication of what it means for an aspect, but no such > luck. That's why I asked. Right. The reason that I brought this up is that it is very curious to use a term informally and formally in the same sentence. (I realize that the formal use is implicit in the original sentence, but it surely is there.) That's confusing to me; it's fine to use the term informally if that's the only way it's used, but that's not the case here. Bob writes: > You went one step further to wonder what the rationale for that rule is, > and I agree with you there, it's kind of curious. It's also curious that the > sentence is in [...], meaning it's implied by other rules -- I wonder what > those rules are. None of this is curious at all. We want indexing to work on T'Class, and for that, the call is dispatching, and it better be the same slot in the tag for all types. Thus changing the name of the subprogram isn't sensible. OTOH, allowing overriding is perfectly OK (as well as new overloadings for the new type), as those fall out of the existing dispatching mechanism. The part of the sentence that forbids changing the aspect is covered formally by 4.1.6(7/3). The rest of the sentence is just standard subprogram rules for type extensions, which (hopefully) don't need to be formally referenced. My first suggestion was just to totally remove the sentence, but upon reflection I think that the point that you can change the meaning of indexing for a type extension by overriding or overloading the subprogram (but not by using a different subprogram with a different name) is one that ought to be mentioned. > I suggest a compromise: AARM annotations, giving an example, and the rationale > (if anybody remembers the rationale), and which rules imply it (if anybody knows). There already is such an AARM note: Ramification: Indexing can be provided for multiple index types by overloading routines with different parameter profiles. For instance, the map containers provide indexing on both cursors and keys by providing pairs of overloaded routines to the Constant_Indexing and Variable_Indexing aspects. Normally, I would also have put a "The Proof" here, but since the actual rule is a whopping 3 paragraphs away, it didn't seem necessary. Maybe I should have simply because it's a forward reference. Why you (Bob) find this so mysterious is odd to me. The objection boils down to using a formal term ("overriding") informally in the same sentence where it is also used formally (implicitly). That's almost certainly going to continue to confuse, since looking up "overriding" in the index is not going to find any references to aspects. As to the exact wording change, there may be a better idea than the one I suggested. Please fire away. Since this is "redundant" text, I didn't want to go through the process of a full AI on the topic (that's clearly overkill). But just putting in an AARM note to explain our poor wording is not much of an answer, since so many people don't read the AARM regularly (from Robert Dewar on down). **************************************************************** From: Randy Brukardt Sent: Wednesday, May 7, 2014 2:33 PM > The rationale is buried in the discussion section of AI05-0139, and > has to do with iterations over a class-wide object initialized with a > derived container. Would be helpful if that was in the AARM. It's much simpler than that. We define indexing on objects of T'Class, and that better have a sensible meaning for derived types in that case. procedure P (Obj : in T'Class) is begin Obj(I) := ...; end P; Obj(I) is a variable indexing, and it will expand into a dispatching call. It better be the case that the dispatching call does the same thing as a statically bound call for a type derived from T. The easiest way to ensure that is to not allow the dispatching slot to be changed (that is, the subprogram name and profile remains the same for all derivations, but of course there can be a new body). This is pretty standard stuff for anything that might dispatch (we don't allow deleting subprograms from a derived type for similar reasons), but perhaps it isn't obvious enough. Iteration (in particular) doesn't enter into the reasons; it shows the problems but you can do that with any object of a class-wide type. **************************************************************** From: Bob Duff Sent: Wednesday, May 7, 2014 2:57 PM > My first suggestion was just to totally remove the sentence, ... Well, if a sentence is both redundant and confusing, removing it makes good sense. And could be considered "editorial", I suppose. > Why you (Bob) find this so mysterious is odd to me. Thanks for the explanations; I get it now. ****************************************************************