!standard 13.1.1(18/4) 15-03-30 AI05-0138-1/08 !standard 13.1.1(34/3) !standard 4.1.5(6/3) !standard 4.1.6(5/3) !standard 4.1.6(6/3) !standard 4.1.6(7/3) !standard 4.1.6(8/3) !standard 4.1.6(9/3) !standard 5.5.1(11/3) !class binding interpretation 14-10-13 !status Corrigendum 2015 15-03-26 !status ARG Approved 8-0-2 15-03-26 !status work item 14-10-13 !status received 14-06-26 !priority Low !difficulty Medium !qualifier Omission !subject Iterators of formal derived types !summary We define the notion of "nonoverridable" aspects, and declare Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing to be nonoverridable aspects. The values of these aspects are names that must not be changed for a derived type (their value can be confirmed), though in each type it is expected that the name might denote different subprograms, types, or discriminants. !question Consider a root type T that has a reversible iterator, and a derivation NT of that type that has only a forward iterator. Then for a generic generic type FT is new T with private; package G is ... In the generic body we could write an iterator using "reverse" for type FT. We would want an instance using NT to fail (since there is no reverse available), but of course there is no recheck in a generic body. There is a contract problem here. !recommendation (See Summary.) !wording Move 13.1.1(34/3) after 13.1.1(18/4). (This is clearly a stand-alone Legality Rule - it uses "shall" - it should be under the correct header.) Add an AARM Reason after the newly moved paragraph: AARM Reason: Most boolean-valued language-defined aspects are associated with a representation pragma. The existing rules for such pragmas assume that the aspect cannot be removed. For instance, if a type T is declared to be Atomic, then all descendants of T are also Atomic. This rule ensures that remains the case when using the aspect notation instead of pragmas. Insert after the new 13.1.1(18.1/4): Certain type-related aspects are defined to be *nonoverridable*; all such aspects are specified using an ASPECT_DEFINITION that is a NAME. If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be *confirming*; that is, the specified NAME shall *match* the inherited aspect, meaning that the specified NAME shall denote the same declarations as would the inherited NAME. If a full type has a partial view, and a given nonoverridable aspect is allowed for both the full view and the partial view, then the given aspect for the partial view and the full view shall be the same: the aspect shall be directly specified only on the partial view; if the full type inherits the aspect, then a matching definition shall be specified (directly or by inheritance) for the partial view. In addition to the places where Legality Rules normally apply (see 12.3), these rules about nonoverridable aspects also apply in the private part of an instance of a generic unit. Redundant: [The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing aspects are nonoverridable.] ---- Add to the Static Semantics section of 4.1.5 (before 4.1.5(6/3)): The Implicit_Dereference aspect is nonoverridable (see 13.1.1). ---- Delete 4.1.6(6-9/3): The Constant_Indexing or Variable_Indexing aspect shall not be specified: - on a derived type if the parent type has the corresponding aspect specified or inherited; or - on a full_type_declaration if the type has a tagged partial view. In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit. Add after 4.1.6(5/3): The Constant_Indexing and Variable_Indexing aspects are nonoverridable (see 13.1.1). ---- Add at the end of the Static Semantics section of 5.5.1 (after 5.5.1(11/3): The Default_Iterator and Iterator_Element aspects are nonoverridable (see 13.1.1). !discussion In 4.1.5, no need to eliminate "if not overridden" wording. It is fine as is because of the possibility of a confirming aspect specification. Similarly, the note in 4.1.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. is fine as it stands. The rules about partial views in the definition of nonoverridable aspects are needed so that privacy is not compromised. The first new rule on partial views (which was originally in 4.1.6) is needed to prevent problems like this one: package Pkg1 is type Rec is record Int : Integer; end record; R1, R2 : aliased Rec; type T1 (D1, D2 : access Rec) is private; generic type Descendant is new T1; package G is X : Descendant (R1'Access, R2'Access); function F return Integer; end; private type T1 (D1, D2 : access Rec) is null record with Implicit_Dereference => D1; -- Illegal by new rule. end; package body Pkg1 is package body G is function F return Integer is (X.Int); end G; end; with Pkg1; package Pkg2 is use Pkg1; type T2 is new T1 with Implicit_Dereference => D2; -- No check here. package I is new G (T2); -- Trouble here if T1 was legal. end; The second new partial-view rule is needed to prevent hidden inheritance. package Pkg3 is type Parent is tagged null record; type Child (D : access Integer) is new Parent with null record with Implicit_Dereference => D; end Pkg3; with Pkg3; package Pkg4 is type Priv is new Pkg3.Parent with private; private type Priv is new Pkg3.Child with null record; -- Illegal by new rule: Priv would have hidden Implicit_Dereference. end Pkg4; with Pkg1; package Pkg4.Child is use Pkg4; type T3 (D2 : access Integer) is new Priv with Implicit_Dereference => D2; -- No check possible here. end Pkg4.Child; Type T3 would have two Implicit_Dereferences, both visible in the body of Pkg4.Child, for different discriminants. !corrigendum 4.1.5(6/3) @dinsb A @fa denotes a view equivalent to that of a dereference of the reference discriminant of the reference object. @dinst The Implicit_Dereference aspect is nonoverridable (see 13.1.1). !corrigendum 4.1.6(5/3) @dinsa An @i is (a view of) a tagged type with at least one of the aspects Constant_Indexing or Variable_Indexing specified. An @i is an object of an indexable container type. A @fa is a @fa that denotes the result of calling a function named by a Constant_Indexing or Variable_Indexing aspect. @dinst The Constant_Indexing and Variable_Indexing aspects are nonoverridable (see 13.1.1). !corrigendum 4.1.6(6/3) @ddel The Constant_Indexing or Variable_Indexing aspect shall not be specified: !corrigendum 4.1.6(7/3) @ddel @xbullet !corrigendum 4.1.6(8/3) @ddel @xbullet if the type has a tagged partial view.> !corrigendum 4.1.6(9/3) @ddel In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit. !corrigendum 5.5.1(11/3) @dinsa An @i is an indexable container type with specified Default_Iterator and Iterator_Element aspects. A @i is an iterable container type with the default iterator type being a reversible terator type. An @i is an object of an iterable container type. A @i is an object of a reversible iterable container type. @dinst The Default_Iterator and Iterator_Element aspects are nonoverridable (see 13.1.1). !corrigendum 13.1.1(18/4) @dinsa A language-defined aspect shall not be specified in an @fa given on a @fa or @fa that is a completion of another declaration. @dinss If an aspect of a derived type is inherited from an ancestor type and has the boolean value True, the inherited value shall not be overridden to have the value False for the derived type, unless otherwise specified in this International Standard. Certain type-related aspects are defined to be @i; all such aspects are specified using an @fa that is a @fa. If a nonoverridable aspect is directly specified for a type @i, then any explicit specification of that aspect for any other descendant of @i shall be @i; that is, the specified @fa shall @i the inherited aspect, meaning that the specified @fa shall denote the same declarations as would the inherited @fa. If a full type has a partial view, and a given nonoverridable aspect is allowed for both the full view and the partial view, then the given aspect for the partial view and the full view shall be the same: the aspect shall be directly specified only on the partial view; if the full type inherits the aspect, then a matching definition shall be specified (directly or by inheritance) for the partial view. In addition to the places where Legality Rules normally apply (see 12.3), these rules about nonoverridable aspects also apply in the private part of an instance of a generic unit. The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing aspects are nonoverridable. !corrigendum 13.1.1(34/3) @ddel If an aspect of a derived type is inherited from an ancestor type and has the boolean value True, the inherited value shall not be overridden to have the value False for the derived type, unless otherwise specified in this International Standard. !ASIS No ASIS effect. !ACATS test We need ACATS B-Tests to verify that the new rules are enforced. !appendix From: Tucker Taft Sent: Tuesday, February 24, 2015 4:07 PM Here is my take on consolidating the rules relating to "immutable" aspects. [ASIDE: I will say I am not thrilled with the use of the term "immutable." Perhaps "inalterable"? "Immutable" to me implies it doesn't change, even by itself, when in fact it can potentially change interpretation if we override the denoted subprogram(s). "Inalterable" to me means that we can't change it, but it might still change interpretation on its own. Also, "immutable" already is associated with "immutably limited," which feels to me like a different sense of the word.] **************************************************************** From: Jeff Cousins Sent: Tuesday, February 24, 2015 4:16 PM Or even unalterable, which would be more a common term (at least in in English English). **************************************************************** From: Jean-Pierre Rosen Sent: Tuesday, February 24, 2015 4:25 PM > [ASIDE: I will say I am not thrilled with the use of the term "immutable." .... Agreed. Why not use "final", like Java final methods that can't be redefined? **************************************************************** From: Tucker Taft Sent: Tuesday, February 24, 2015 4:33 PM I do not find the term "final" much clearer, unfortunately. Is that your "final aspect"? This is my final aspect! Sounds like a game show... ;-) **************************************************************** From: Tucker Taft Sent: Tuesday, February 24, 2015 4:27 PM > Here is my take on consolidating the rules relating to "immutable" aspects. ... Oops, noticed some sloppy wording. Here are replacements for two of the critical paragraphs: An immutable aspect shall not be directly specified on a full_type_declaration if the type has a partial view that would allow the specification of the same aspect. If a type with a partial view inherits an immutable aspect, then a matching definition shall be specified for this immutable aspect of the partial view. In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit. **************************************************************** From: Randy Brukardt Sent: Tuesday, February 24, 2015 5:24 PM > Here is my take on consolidating the rules relating to "immutable" > aspects. A quick glance at this suggests that you didn't update the discussion, which is talking about "new legality rules added to 4.1.5, 4.1.6, and 5.5.1", and then talks about the "first" and "second" new rule. (With your wording, there is only one rule in each subclause.) I suspect that the discussion is really now about the rules in the new blanket definition. > [ASIDE: I will say I am not thrilled with the use of the term > "immutable." Perhaps "inalterable"? "Immutable" to me implies it > doesn't change, even by itself, when in fact it can potentially change > interpretation if we override the denoted subprogram(s). > "Inalterable" to me means that we can't change it, but it might still > change interpretation on its own. Also, "immutable" already is > associated with "immutably limited," > which feels to me like a different sense of the word.] I'm not wedded to any specific term here. "Inalterable" or "unalterable" is OK by me. I'm not sure that either is really better, I do agree that there's some possible confusion with "immutably limited", which is more important of a concept. My (lousy) thesaurus gives: "immutable, permanent, changeless, eternal" for opposites of "mutable". For "alteration" (the closest to "alter" that it comes), I get forms of fixed, stable, and identity as well as some of the above. "Permanent aspect" might work; "eternal aspect" maybe not. ;-) **************************************************************** From: Randy Brukardt Sent: Tuesday, February 24, 2015 5:42 PM Another oddity: you removed the generic boilerplate from the new text in 4.1.5, because you included it in the definition of "immutable aspect". But you left it in the new text for 5.5.1. I would have expected 4.1.5 and 5.5.1 to be treated the same. **************************************************************** From: Randy Brukardt Sent: Tuesday, February 24, 2015 5:58 PM Humm. You have (I suspect that Steve had originally) placed the definition of "immutable aspect" into 13.1.1(34), followed by a bunch of Legality Rules, including the boilerplate. But this is a "Static Semantics" section; there aren't any "Legality Rules" here; so the boilerplate does have any effect. Not what we want. This text should go in the Legality Rules section. And the generic boilerplate here probably needs to make clear that the Legality Rules its talking about are those for "immutable aspects" and not (necessarily) all of the other rules in this clause. (That's always a problem when one uses "these rules", but here it seems acute. Of course, the question arises whether in fact the rest of these rules need the boilerplate as well, since about 98% of the time that's true, but I don't want to make my head hurt. :-) So how about: In addition to the places where Legality Rules normally apply (see 12.3), these rules {for immutable aspects} apply also in the private part of an instance of a generic unit. **************************************************************** From: Bob Duff Sent: Tuesday, February 24, 2015 6:03 PM > [ASIDE: I will say I am not thrilled with the use of the term > "immutable." I agree with your reasons for being unthrilled. > ...Perhaps > "inalterable"? I don't think that's a word. "unalterable", perhaps. Or "static" (inspired by J-P's suggestion of "final"). ;-) Or "unutterable"? ;-) ;-) More seriously, do we really need yet more magic words? Can't we just say "Blah shall not be redefined..." or some such? **************************************************************** From: Randy Brukardt Sent: Tuesday, February 24, 2015 6:25 PM I don't think that would work. Tucker wants to move this bunch of rules into 13.1.1 rather than repeating them in each place (three places currently, but it's easy to imagine more in future aspects). In order for that to make any sense at all, we need some sort of term so the reader knows that the rules are incomplete at the point of definition and that they need to look in 13.1.1 to find the rest. In the absence of such a term, I'd rather just duplicate the rules as Steve originally had done rather than to put some of the rules somewhere that no one would look naturally. But I agree that's a future maintenance hazard. More generally, blanket rules really only work when they apply to everything (as in the resolution of aspect specifications), not as well in cases like this when they apply to a narrowly defined subset of something. I'm rather dubious that the blanket rules proposed in AI12-0153-1 are worth the effort, for example; if we did make the changes, a term would make the fact that they apply clearer. (Not that I want to come up with such a term.) We'll probably discuss this more on Thursday. **************************************************************** From: Vincent Celier Sent: Tuesday, February 24, 2015 6:56 PM >> ...Perhaps >> >"inalterable"? > I don't think that's a word. "unalterable", perhaps. I believe inalterable is a word, bot in French and in English. http://en.wiktionary.org/wiki/inalterable **************************************************************** From: Dr. Joyce L Tokar Sent: Tuesday, February 24, 2015 8:20 PM Both are words....inalterable is the older version (1535-45) whereas unalterable is from 1610-1615. They have the same meaning and both are found in common usage in the English language today. **************************************************************** From: Tucker Taft Sent: Tuesday, February 24, 2015 9:25 PM >> Here is my take on consolidating the rules relating to "immutable" >> aspects. > > A quick glance at this suggests that you didn't update the discussion, > which is talking about "new legality rules added to 4.1.5, 4.1.6, and > 5.5.1", and then talks about the "first" and "second" new rule. (With > your wording, there is only one rule in each subclause.) I suspect > that the discussion is really now about the rules in the new blanket > definition. Yes, sorry about that. Without looking I presumed the discussion didn't need change, since I was just moving the rules around. But clearly I was wrong! >> [ASIDE: I will say I am not thrilled with the use of the term >> "immutable." Perhaps "inalterable"? > ... I get forms of fixed ... How about fixed and floating aspects? ;-) > "Permanent aspect" might work; "eternal aspect" maybe not. ;-) "Permanent" isn't too bad, but the opposite of "permanent" is typically "temporary," and that doesn't really make sense. So I think I would still suggest "inalterable." Reminds one a bit of "inalienable" ... [actually, an interesting side story there -- Thomas Jefferson wrote "inalienable" in his original version of the Declaration of Independence, but John Adams changed it to "unalienable" when he copied it over for the final printing -- tnx to ushistory.org]. **************************************************************** From: Tucker Taft Sent: Tuesday, February 24, 2015 9:27 PM >> Here is my take on consolidating the rules relating to "immutable" >> aspects. > > Another oddity: you removed the generic boilerplate from the new text > in 4.1.5, because you included it in the definition of "immutable > aspect". But you left it in the new text for 5.5.1. I would have > expected 4.1.5 and 5.5.1 to be treated the same. Oops again! **************************************************************** From: Robert Dewar Sent: Wednesday, February 25, 2015 4:28 AM > Both are words....inalterable is the older version (1535-45) whereas > unalterable is from 1610-1615. They have the same meaning and both > are found in common usage in the English language today. To my british ear, unalterable sounds much preferable, though inalterable wins the google race by a factor of 9. **************************************************************** From: John Barnes Sent: Wednesday, February 25, 2015 5:52 AM Oxford seems to suggest that unalterable is preferrred in that it defines inalterable as unalterable. It also notes that unaltered means not castrated! Fowler is not much help. It says that historically one would expect un with English words and in with Latin words but then says it's a mess. Note assymetric pairs such as unstable and instability. I would go for un I think. Hmm. Not sure. **************************************************************** From: Brad Moore Sent: Wednesday, February 25, 2015 9:11 AM Would one normally alter their aspects? Maybe its just me, but I find this to be a somewhat odd thing to say. I had to alter the Pre'Class aspect of my derived class. I think one would normally speak of either replacing or modifying an aspect, so irreplaceable or unmodifiable seems a closer fit. How important is it to be a word that you can find in the dictionary? This property is tied to derivation so it seems it might be clearer and more precise to say unsupersedable, however that does not appear to be a word even though its base, supersede is an English word. In any case, I am not married to any of these choices, so I suppose one might say I am unaltarable to any of these choices. If I had to choose though, I think I would go with irreplaceable. **************************************************************** From: Tucker Taft Sent: Wednesday, February 25, 2015 1:44 PM Here is an update to AI12-0138, switching to "unalterable" term, and fixing the discussion. I also changed the statements about "blah is an unalterable aspect" to be Static Semantics, as the legality rules have moved to 13.1.1. By the way, another possible alternative I thought of to "unalterable" is "stable." **************************************************************** From: Steve Baird Sent: Wednesday, February 25, 2015 3:09 PM > Here is an update to AI12-0138, switching to "unalterable" term, We could also consider "irrevocable ", "irrevocably specified", or "binding". **************************************************************** From: Tucker Taft Sent: Wednesday, February 25, 2015 3:49 PM I like "irrevocable." Alternatively, given the definition of "overridden" given in 13.1(15/3) for aspects, I think "non-overridable" would convey exactly the correct semantics. Is there some reason we didn't like that term? It seems sort of obviously correct in hindsight. **************************************************************** From: Steve Baird Sent: Wednesday, February 25, 2015 4:04 PM I agree, "non-overridable" is clearer than anything else we've discussed. **************************************************************** From: Robert Dewar Sent: Wednesday, February 25, 2015 4:07 PM Especially if this is all about overriding, rather than altering per se! I like this suggestion. **************************************************************** From: Randy Brukardt Sent: Wednesday, February 25, 2015 4:11 PM > >> Here is an update to AI12-0138, switching to "unalterable" term, > > > > We could also consider "irrevocable ", "irrevocably specified", or > > "binding". > > I like "irrevocable." Alternatively, given the definition of > "overridden" given in > 13.1(15/3) for aspects, I think "non-overridable" would convey exactly > the correct semantics. Is there some reason we didn't like that term? > It seems sort of obviously correct in hindsight. Probably because 13.1(15) is not intended to define a term "overridden"; it's not in italics, it's not indexed, etc. I thought that was an "English" use of "overridden". (Or perhaps I never thought of it at all.) Indeed, we had an entire AI on this topic: "AI12-0104-1 Overriding an aspect is undefined", where we got rid of wording that talked about "overriding" an aspect, because no such thing was thought to be defined. Either we didn't think 13.1(15) defined the term, or no one even found that reference. To change course yet again would require changing 13.1(15) to italicize the term, and then revisiting the various AIs (I think there may have been more) to determine what changes need to be made to them. Certainly not something that we should do tonight nor during tomorrow's meeting [we could decide intent at most]. We'd have to have either an additional phone meeting or a bunch of letter ballots to deal with that afterwards. **************************************************************** From: Randy Brukardt Sent: Wednesday, February 25, 2015 4:21 PM > > Alternatively, given the definition of "overridden" given in > > 13.1(15/3) for aspects, I think "non-overridable" would convey > > exactly the correct semantics. Is there some reason we didn't like > > that term? It seems sort of obviously correct in hindsight. > > I agree, "non-overridable" is clearer than anything else we've > discussed. [I want to scream, but I'm afraid that it might bother my neighbors in this office building. :-)] Surely it's "clearer". If we thought it meant anything, we never would have had any of these AIs in the first place, because the original Ada 2012 wording said that most of these aspects were not overriddable (without explaining the consequences). But Ed asked what that meant, since "overriding an aspect" isn't defined. So we got rid of that wording, especially as it was marked as redundant. But that caused Steve to ask one of his typical questions about generic derived types and these aspects. Which I noted was more general than the obscure case he asked about. Thus some wording was proposed to plug the hole. Which led to an argument about the term to use. Which now seems to have settled on virtually the original wording (with some additional rules to back it up). Once we adopt that, we can start the whole chain over again. "There's a hole in the bucket, a hole!!!" - Ancient folk song. **************************************************************** From: Tucker Taft Sent: Wednesday, February 25, 2015 4:26 PM >> ... Alternatively, given the definition of "overridden" given in >> 13.1(15/3) for aspects, I think "non-overridable" would convey >> exactly the correct semantics. Is there some reason we didn't like >> that term? It seems sort of obviously correct in hindsight. > > Probably because 13.1(15) is not intended to define a term > "overridden"; it's not in italics, it's not indexed, etc. I thought that was > an "English" use of "overridden". (Or perhaps I never thought of it at all.) > > Indeed, we had an entire AI on this topic: "AI12-0104-1 Overriding an > aspect is undefined", where we got rid of wording that talked about > "overriding" an aspect, because no such thing was thought to be defined. Interesting! A bit of history my brain conveniently forgot. > Either we didn't think 13.1(15) defined the term, or no one even found > that reference. > > To change course yet again would require changing 13.1(15) to > italicize the term, and then revisiting the various AIs (I think there > may have been more) to determine what changes need to be made to them. > Certainly not something that we should do tonight nor during > tomorrow's meeting [we could decide intent at most]. We'd have to have > either an additional phone meeting or a bunch of letter ballots to deal with > that afterwards. I think the term "overriding" for aspects is intuitive, and I can't remember why we chose to abandon it. So I would be in favor of enshrining "overriding an aspect" as an official term, and then use it where appropriate. And yes, I can sympathize with your desire to scream... ;-) **************************************************************** From: Randy Brukardt Sent: Wednesday, February 25, 2015 4:28 PM > > I agree, "non-overridable" is clearer than anything else we've > > discussed. > > Especially if this is all about overriding, rather than altering per > se! I like this suggestion. To turn to a technical objection, it seems to me that that could be confusing. After all, the entity designated by the aspect can be overridden or overloaded (for Constant_Indexing/Variable_Indexing in particular), what you can't do is change (alter?) the entity designated. We've generally not used the term "override" with aspects (other than the one sentence Tuck dug up); they are outright replaced. Perhaps that is something that we should rethink, but I don't think it's a good idea to do that at 23:58 in this particular process. **************************************************************** From: Tucker Taft Sent: Wednesday, February 25, 2015 4:35 PM > To turn to a technical objection, it seems to me that that could be > confusing. After all, the entity designated by the aspect can be > overridden or overloaded (for Constant_Indexing/Variable_Indexing in > particular), what you can't do is change (alter?) the entity > designated. We've generally not used the term "override" with aspects > (other than the one sentence Tuck dug up); they are outright replaced. Actually, the term "overridden" appears in 13.1(15.1/3) as well, and in AARM paragraphs 13.1(15.a, 15.b.1/3). > Perhaps that is something that we should rethink, but I don't think > it's a good idea to do that at 23:58 in this particular process. Not sure I agree. If we are introducing a new term at 23:58, that seems worse to me. Straightening out the usage of a term that already appears in the standard makes perfect sense in a corrigendum, especially if it makes intuitive sense to most folks. **************************************************************** From: Randy Brukardt Sent: Wednesday, February 25, 2015 4:53 PM ... > > Perhaps that is something that we should rethink, but I don't think > > it's a good idea to do that at 23:58 in this particular process. > > Not sure I agree. If we are introducing a new term at 23:58, that > seems worse to me. > Straightening out the usage of a term that already appears in the > standard makes perfect sense in a corrigendum, especially if it makes > intuitive sense to most folks. I'm mostly against re-introducing a term that was thought not to be defined at 23:58, with an unspecified scope of changes to accommodate that. (That is, voting tomorrow to have the editor straighten it out without an additional vote.) That's something we should think through carefully to ensure that we haven't introduced additional problems, not do as a rush. If you had made this suggestion on Friday, I still would have screamed, but there would have been time to deal with it. As it is, I need to post the agenda in the next couple of hours (and I still have to finish AI12-0152-1) so that our west coast members have a chance to read the AIs before tomorrow's meeting. (I don't think anyone should be forced to get up at 6 am their time to be prepared for an ARG meeting.) I still think we'll need to introduce "nonoverriddable aspect" as a term, since there is a bunch of specific Legality Rules triggered. (Note: I don't think there is a hyphen in here, as this is a new term and the anti-hyphen forces won that debate -- we only use hyphens after "non" in words already extensive used in the Standard.) That's not something we would want to have people figure out by guessing what the consequences are. :-) **************************************************************** From: Tucker Taft Sent: Wednesday, February 25, 2015 5:15 PM ... > If you had made this suggestion on Friday, I still would have > screamed, but there would have been time to deal with it. As it is, I > need to post the agenda in the next couple of hours (and I still have > to finish AI12-0152-1) so that our west coast members have a chance to > read the AIs before tomorrow's meeting. (I don't think anyone should > be forced to get up at 6 am their time to be prepared for an ARG > meeting.) I agree we should not try to solve this entire problem tomorrow. But I do think we should address it in the upcoming Corrigendum. > I still think we'll need to introduce "nonoverriddable aspect" as a > term, since there is a bunch of specific Legality Rules triggered. Yes, I agree with that. **************************************************************** From: Randy Brukardt Sent: Wednesday, February 25, 2015 5:38 PM > Actually, the term "overridden" appears in 13.1(15.1/3) as well, and > in AARM paragraphs 13.1(15.a, 15.b.1/3). True enough, but the other normative paragraph is a mirror of 13.1(15/3), and the appearance in the associated notes isn't very compelling, either. I probably should have said that we don't use "overriding an aspect" in any language rules, so far as I can remember; that's probably why we never defined it as a term. > > Perhaps that is something that we should rethink, but I don't think > > it's a good idea to do that at 23:58 in this particular process. > > Not sure I agree. If we are introducing a new term at 23:58, that > seems worse to me. > Straightening out the usage of a term that already appears in the > standard makes perfect sense in a corrigendum, especially if it makes > intuitive sense to most folks. I think I prefer "irrevocable" as Steve suggested, because it has the closest connotation to the intended meaning (you can specify it once but not change it). I think "nonoverridable aspect" is likely to be confused with not being able to override the specified subprogram, which is definitely not what we mean. But I don't think the exact term matters that much; making sure that the rules are well-defined matters more. **************************************************************** From: Tucker Taft Sent: Tuesday, March 24, 2015 2:27 PM I believe this is the only "corrigendum" AI still outstanding. [This is version /06 of the AI - Editor.] I tried to make the wording easier to understand, with the rationale implicit in the wording itself. I also indicated that nonoverridable aspects are always specified by NAMEs, so it makes sense to talk about what they "denote." I hope this will also make it clearer that we are saying that the NAME is inherited, even if the denoted entities might not be. **************************************************************** From: Randy Brukardt Sent: Friday, March 27, 2015 8:55 PM Yesterday, we decided to insert "Legality Rules" before 13.1.1(34), along with the new rules. Does anyone know why we have the rules here (paragragh 34) rather than in the Legality Rules section for this clause? Having multiple Legality Rules portions of a clause is allowed but discouraged. In particular, it would seem OK to move the existing 13.1.1(34/3) and the following new rules after 13.1.1(18/3). There's nothing wrong with including definitions like "nonoverriding" in Legality Rules (we do it all the time, especially when, as in this case, the definition is primarily used in a Legality Rule). There is absolutely no doubt that 13.1.1(34/3) is a Legality Rule (I see "shall" :-): If an aspect of a derived type is inherited from an ancestor type and has the boolean value True, the inherited value shall not be overridden to have the value False for the derived type, unless otherwise specified in this International Standard. And it doesn't have anything to do with the wording above it that I can see. (Aspect inheritance is defined in 13.1, not in 13.1.1.) Thus we can place it anywhere. The same goes for the new wording: Certain type-related aspects are defined to be *nonoverridable*; all such aspects are specified using an ASPECT_DEFINITION that is a NAME. If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be *confirming*; that is, the specified NAME shall *match* the inherited aspect, meaning that the specified NAME shall denote the same declarations as would the inherited NAME. If a full type has a partial view, and a given nonoverridable aspect is allowed for both the full view and the partial view, then the given aspect for the partial view and the full view shall be the same: the aspect shall be directly specified only on the partial view; if the full type inherits the aspect, then a matching definition shall be specified (directly or by inheritance) for the partial view. In addition to the places where Legality Rules normally apply (see 12.3), these rules about nonoverridable aspects apply also in the private part of an instance of a generic unit. Redundant: [The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing aspects are nonoverridable.] "type-related" is defined in 13.1. This doesn't use anything else defined in 13.1.1. Thus, my "editorial review" of this AI is to suggest putting these rules after 13.1.1(18) at the end of the existing Legality Rules segment, rather than adding a second one. And move 13.1.1(34/3) while we're at it, since it's already misplaced. Any objections?? **************************************************************** From: Tucker Taft Sent: Saturday, March 28, 2015 10:50 AM Makes sense to me! **************************************************************** From: Jeff Cousins Sent: Monday, March 30, 2015 3:44 AM It sounds good to me to group like things together. **************************************************************** From: Erhard Ploedereder Sent: Monday, March 30, 2015 6:11 AM Agreed. But aren't 13.1.1. (31) through (33) also Legality Rules as opposed to Static Semantics (and therefore should move up as well) ? **************************************************************** From: Randy Brukardt Sent: Monday, March 30, 2015 3:26 PM I thought about that, and I don't think they should move. 13.1.1(31/3) and 13.1.1(33/3) are expressions of capability (no "shalls" in there), and thus normally would be under Static Semantics. 13.1.1(32/4) is a mixed bag: The first sentence is also capability, and the last sentence (the new one) also is descriptive. The second sentence is Name Resolution (it gives the expected type). The third sentence is indeed a Legality Rule (note the use of "shall"). So of the six sentences, 3 are clearly Static Semantics, one is mostly Static Semantics (and definitely not written in the form of a Legality Rule - it defines when something happens, not the consequences of that which is the only way to read it as a Legality Rule), one is Name Resolution, and one is a Legality Rule. As such, it seems best to leave it where it is, since it isn't clear-cut better in the new location, and we're not here to move stuff just because we can. I suspect 13.1.1(34/3) was put after 13.1.1(31-33/3) because the need comes from those rules. But it stands alone fine (there's nothing about why the aspect is Boolean), so it seems better in the Legality Rules section. There probably ought to be an AARM note to explain the reason for this rule in its new position, but that's already the case (it's surely not obvious). ****************************************************************