Minutes of the 52nd ARG Meeting
18-19 October 2014
Portland, Oregon, USA
Attendees: Steve Baird, Randy Brukardt, Gary Dismukes, Erhard Ploedereder, Tucker Taft, Brad Moore, Jeff Cousins, John Barnes.
Observers: Steve Michell.
The meeting convened on Saturday, 18 October 2014 at 09:15 hours and adjourned at 17:50 hours on Sunday, 19 October 2014. The meeting was held at the Portland Marriott Downtown Waterfront. The meeting covered all of the normal AIs and some of the amendment AIs on the agenda.
Tuillo Vardanega, Robert Dewar, and Alan Burns sent apologies for not being able to attend.
Randy had previously posted a second draft of the minutes with the various corrections that had been submitted.
Approve minutes: 8-0-0.
Next meeting: June in Madrid, associated with the Ada-Europe conference. The conference organizers will give us the exact dates. [Appears to be June 26-28, 2015 – Editor.]
Do we need a winter meeting? Let's decide at the close of the meeting. IRTAW is too late (mid-April), too close to June. Many people want a Florida location if we have a meeting. On Sunday morning, Steve Michell notes that Greg Gicca (who is here) would be willing to help us set up a February meeting in St. Petersburg, if we decide to have a meeting.
On Sunday evening, we reconsidered the winter meeting question. We made so much progress here that we probably don't need one. So we'll just plan on a phone meeting or two.
We try to set a date for the first phone meeting. Tucker says that Tuesdays are bad for him. Preliminary date January 28, at noon eastern.
Thanks to the editor (Randy Brukardt) for taking the minutes.
Thanks to SIGAda for the accommodations.
Thanks to the Rapporteur (Jeff Cousins) for running the meeting.
Randy had noted that any Amendment AI that doesn't involve syntax could be included in the Corrigendum. We look at all of the Amendment AIs, and suggest that we consider the following AIs for inclusion:
These are all discussed individually later in the meeting (see below), along with several other Amendment AIs.
Steve Baird has AI12-0016-1 (outline of paper) and AI12-0020-1 unfinished. Nothing on these have changed since last time, however AdaCore is planning to try to implement one of the AI12-0016-1 schemes.
Randy Brukardt notes that he didn't work on AI12-0112-1 as it is not intended for the Corrigendum and AdaCore decided not to fund his work on it at this time.
Ed Schonberg (AI12-0002-1, AI12-0111-1) isn't here to explain his sloth.
Tucker Taft has AI12-0058-1 (along with Ed and Van). Tucker forgot that he'd promised to work on wording changes for this AI. Tucker did AI12-0064-1 after the deadline, as Randy forgot to put it in his action item list.
John didn't do any work on the Corrigendum introduction, mainly because Randy didn't ask him.
The combined unfinished old action items and new action items from the meeting are shown below. (* indicates an AI that we'd like to be able to put into the Corrigendum, ? indicates an AI that we'd put into the Corrigendum if it was finished in time, but that seems unlikely because of the amount of work remaining.)
The minutes cover detailed review of Ada 2012 AIs (AI12s). The AI12s are presented in numeric order, which is not necessarily the order in which they were discussed. Votes are recorded as “for”-“against”-“abstentions”. For instance, a vote of 6-1-2 would have had six votes for, one vote against, and two abstentions.
If a paragraph number is identified as coming from the working Ada 202x AARM, the number refers to the text in draft 4 of the Ada 202x AARM. Paragraph numbers in other drafts may vary. Other paragraph numbers come from the final Ada 2012 AARM; again the paragraph numbers in the many drafts may vary.
The subject should say “Specifying the standard storage pool”.
Since Standard could be an identifier, we need some preference rule. As this is an identifier specific to the pragma, it is not resolved.
Tucker would like there to be an indication of a preference for the identifier specific to the pragma.
Tucker says that another possibly would be to have no argument at all. Randy notes that would not work very well for the aspect Default_Storage_Pool.
Steve Baird suggests using <>. Someone objects that that is new syntax.
Tucker suggests Standard'Storage_Pool. Steve hates this, because it seems to denote a single object. Beyond that, it makes little sense to have an attribute that only allows a single package as a prefix (along with access types). That's the same resolution problem that we would have with using Standard.
Steve Baird says that the standard pool is a policy, not an object. He wants it to look like a policy, not like an individual object.
Standard is specific to a pragma and no resolution; 4
Resolves to an object, else identifier specific to a pragma. 0
Resolves to package Standard; 3
Straw vote: standard'storage 3; standard as identifer 4
Tucker suggests that it is illegal if (without any context) if it (Standard) denotes anything other than package Standard. That's just a bare lookup – anything that is visible would trigger the error. Otherwise, it is treated as an identifier specific to the pragma/aspect.
Brad will attempt to write it up using this semantics. He also will add the wording needed for aspect Default_Storage_Pool.
Approve intent: 7-0-0.
Randy notes that he didn't propose the pragma Restriction identifier for Ada_95_Only and so on, which is necessary for this to make much sense.
Steve Baird thinks that this doesn't believe belong in the Standard, since we don't usually talk about Ada language versions.
We agree that this doesn't belong in the Corrigendum, and maybe only as an implementation-defined thing.
Not in the corrigendum: 8-0-0.
Tucker explains his examples.
Erhard worries about transitive usage of this. For instance, put the record type in the Pure package. Looks like the wording doesn't work in that case.
Steve Baird worries about controlled types used in Pure and Shared_Passive packages. These have some global finalization effects. No one sees an obvious problem, but as this is a new capability in Ada 2012 (Controlled was preelaborated in Ada 2005), there is a possible issue.
We worry about a Pure package has limited private type with an access component, and a constructor. In that case, we'd have to break privacy to check.
package P1
with Pure is
type Lim is limited private;
function Construct (A : access Integer) return Lim;
procedure Update (Obj : in out Lim; B : access Integer);
private
type Pure_Acc is access all Integer
with Storage_Size => 0;
type Lim is record
P : Pure_Acc;
end record;
end P1;
package body P1 is
function Construct (A : access Integer) return Lim is
begin
return (P => A);
end Construct;
procedure Update (Obj : in out Lim; B : access Integer) is
begin
Obj.P := B;
end Update;
end P1;
package P2 is
X : aliased Integer;
end P2;
with P1;
package P3
with Shared_Passive is
type Rec is record
P : P1.Lim;
end record;
I : aliased Integer;
V : Rec := (P => P1.Construct(I'Access));
end P3;
with P1, P2, P3;
package P4 is
P1.Update(P3.V, P2.X'Access); -- ??
-- Stores an access to an object declared in a normal package
-- into an object declared in a Shared_Passive package.
end P4;
Tucker worries that an access value could be created earlier before any shared passive package is involved. Then the check is too late.
Tucker suggests a solution based on ghost types. That's too weird.
We need to ban access types that come from a pure package.
The conservative rule would make all private types illegal, which is too incompatible.
A privacy-breaking rule is suggested. Use of a type with buried access types is illegal.
Steve then asks about access-to-class-wide, for which extension components have this property. We think that's already illegal for shared passive packages.
The privacy breaking rule would make the component of type Rec in Tucker's example illegal.
Similarly in Randy's example (Lim has a hidden access type).
The AI goes back to Tucker for rewording.
Approve intent of AI: 6-0-2.
In the proposal, change “combination” to “conjunction” to make it crystal clear how they combine.
7.3.2(1/3) needs to say “private type, private extension, or interface”.
Steve worries that a record extension that implements an interface would not check if the type is not in a package specification. That's OK, as type invariants don't make any sense on types that are visible – it doesn't make sense to just make checks at particular points since things can change anywhere.
Steve would prefer the “nice clean model” of always checking every invariant on every primitive operation of a descendant.
Tucker notes that an abstract private type with no components is essentially the same as an interface. So the checks should be done the same way.
Gary: Fix in example: Window.Get_Width and Window.Get_Height (only the current instance is visible in the invariant).
Change to Binding Interpretation.
Approve AI with changes: 6-0-2.
We have a brief discussion on this AI. Tucker suggests that Object_Size = 0 is defined to be the default, and it means that no size was specified. Randy will look at that as a possibility.
Such a function can be completed by an exception or by abort.
This seems to be much less important as we now have raise expressions; it's no longer necessary to write an exception raising function to get a particular exception to be raised by an expression evaluation.
Randy suggests voting this hold.
Hold AI: 8-0-0.
Not nonblocking would be an annoying double negative. We therefore want to use Potentially_Blocking as the name of the aspect.
Do we want this in the corrigendum? Randy says he does, but he didn't think we could get it done. Tucker notes that we need to put this on all of the language-defined subprograms. Randy notes that 9.5.1(18) already says which subprograms need Potentially_Blocking => True and which need Potentially_Blocking => False.
Steve Baird wonders if this is two valued (True or False) or three-valued (True, False, unspecified). Tucker says that he intended the first.
If this is compile-time enforcement, it's weird to put it into a Bounded Error section. Steve had only runtime checks.
We need to have it on generic formals. We want to statically check that the aspect doesn't lie. (We don't want to make such a check by default for 9.5.1(8), because that would be very incompatible. We should have a restriction that 9.5.1(8) is checked statically, that's even better than pragma Detect_Blocking).
Steve Baird asks about Finalization, storage pools, etc. These are not always known to the compiler. Requiring all extensions to be non-blocking would be rather incompatible.
The AI goes back to Tucker for a real wording proposal.
Tucker thinks the wording is insanely long for this change. Randy says that he tried to shorten Steve's wording but failed; everything Steve says seems to need to be there. Tucker is unconvinced.
Hand to Tucker to shorten wording. We'd like to have this in the Corrigendum if possible.
Approve intent of AI: 7-1-0.
John is against messing with the language definition for this problem.
Steve Baird notes that the goal is that the caller should be able to rely on the postconditions of an entry even if the implementation of the entry uses a requeue. Similarly, the implementation (body) of an entry should be able to rely on its preconditions no matter how it is invoked.
Typo in wording: Jeff “parmeter”, Erhard “the the”, Tucker “there shall be exists” should be “there shall exist”. 5/3 (4 th para): Missing comma after redundant text.
In para “If the requeue target”, “the requeue target is declared immediately with” (should be “within”).
The P1 and E1 and P2 and E2 are confusing. The wording is backwards compared to the question. Change all of the P1 to P2 and vice versa, as well as E1 to E2, etc.
Steve worries that the actual rule is backwards. E1 is the (original) entry, and E2 is the requeue target. So we want the rule to be reversed, and the numbers are right.
Erhard suggests dropping the “enabled or not” (two places), as this is a Legality Rule, enabling is a dynamic construct.
Randy e-mails the wording changes to the group.
Steve Michell notes that one can use the entry family index in a postcondition. [This appears to be wrong, as an entry family index does not have a name in an entry_declaration – Editor.] Since you can internally requeue to a different entry family, that could cause the postcondition to be a lie. Do we care? (We're not trying to fix all such cases.)
Tucker suggests that the postcondition cannot depend on an entry index. So add that to the 'Old rule.
13.1.1(12/3) says that formal parameters are visible; that needs to include the entry family index. [Again, since it doesn't have a visible name, there's no way for it to be visible. 13.1.1(12/3) is OK as is. - Editor.]
There is a discussion about whether the wording works if the target is parameterless. The conclusion is that it does because it starts with P2 (which may have no parameters), not P1.
Approve AI with changes: 7-0-0.
Randy notes that this was originally billed as not requiring any wording changes, but now we have 10 paragraphs that are changed. It no longer seems so trivial.
Straw pool: For: 0; Against: 1; Abstain: 7.
Tucker notes that many C implementations have it, but it's never made it to the C standard.
Hold AI: 8-0-0.
Drop the 7.1 in front of the bullet, and make the editorial change noted in the editorial note.
Add this after 8.1(2), rather than after 8.1(6).
Actually, access_to_subprogram_definition is a stand-alone type declaration. So we don't need a rule for it. We need this to cover access_definition, not access_to_subprogram_definition.
That should be changed everywhere in the AI.
Approve AI with changes: 7-0-1.
Tucker would like this to say proper_body, body_stub, or entry_body.
3.f should drop the first sentence (since it's clear from the wording).
The renames-as-body wording (AI12-0132-1) should immediately follow this one.
Randy notes that he put this after 13.14(5/3) to keep all of the not-quite-bodies together. That is agreed on. (So in AI12-0132-1, move the change after 13.14(5/3)).
AARM 13.14(3.g):
Approve AI with changes: 6-0-2.
Tuck defined the term “class-wide aspect”, and the “unless specified otherwise”.
Randy notes that 13.1.1(36/3) already covers the “unless specified otherwise”. Tucker thinks it's good to be explicit (and no one else agrees with Randy that the text is unnecessary).
The cross-reference should be to AI12-0121-1.
Approve AI with change: 7-0-1.
Tucker asks where this came from. It came out of a Steve Baird discussion, it wasn't from a user.
Tucker thinks we shouldn't force any compiler to change behavior here. Thus we don't want to decide the actual question. Classify this as a pathology, and we won't decide anything. Thus the wording stays the same.
Change classification to Pathology, then No Action: 8-0-0.
Tucker suggests dropping the second bullet, as it is incompatible, and while the case is dangerous, it is not worth handling. Besides, it provides a work-around for 13.1(10/3), and probably some people have found it.
For question 2, Randy notes that the literal wording has the effect that we want, so he just recommends adding an AARM note that hand-stands are needed.
Dump the parenthetical remark (we believe...) from the AARM note for 15.1.b. Modify the remainder:
First paragraph of the discussion, insert “an” before “inherited primitive subprogram”.
Drop “Rather than pick a fight with them...”
There is clearly a possibility of anomolies given that the aspect has neither (spelling of anomalies).
Approve AI with changes: 7-0-1.
Tucker wants to know about the known overhead problem. Randy says that it mainly comes from A.18.2(148.17/3) and similar rules; the finalization overhead on a common operation is too much.
Tucker wonders if the overhead can be eliminated when one is in an iterator and tampering is already set. Randy notes that it certainly can be eliminated if the life of the reference object is short enough that no calls are made during its lifetime.
Tucker and Randy go into a long discussion about possible changes to the rules. Randy notes that tampering with cursors (as an iterator uses) and tampering with elements (which Reference, etc. use) are different. Tucker suggests that the rule would just be tampering with cursors for Reference/Constant_Reference other than in indefinite containers. That already applies during the entire loop, so only a single state change would be needed, eliminating most of the expense. [Unfortunately, I didn't record why he thought that eliminating the extra protection of “tampering with elements” would be OK for a loop – Editor.] Of iterators in particular can be converted automatically because the uses of Reference are implicit in the iterator.
Tucker will try to write up this idea. He also will try to convince Ed (or someone else) to do some performance tests and/or implementation prototyping.
Erhard says that he had a student project that was 10 times faster on a JVM versus Ada. We would like to see some such examples so we can see if we can increase the performance.
Keep alive: 8-0-0.
Tucker explains that the model has been changed to a formal derived type model.
6.1.1(18/3):
The fix to the original bug is that we use the “controlling tag” to determine which body is called for any primitive operations.
Tucker is wondering what happens if you reference Obj'Tag in Pre'Class. This attribute only works on class-wide objects (which these aren't), and converting to T'Class puts us into the dynamic realm. So all is OK.
Tucker says type invariants don't have this problem. Randy refers to 7.3.2(5/3) which says that Type_Invariant'Class has T'Class. Tucker is not happy, but is convinced. He will take the Type_Invariant case in a new AI (split from this one).
Randy will take a stab at adding wording for class-wide postconditions. Here it is:
In 6.1.1(7/3): “though it had a (notional) type NT that is a [visible] formal derived type whose ancestor type is T{, with directly visible primitive operations}”
Approve AI with changes: 5-0-3.
The “this ensures” paragraph only applies to Ravenscar, and as such should probably just be dropped.
Next paragraph: “compilation” to “complication”.
We should have a dynamic check, so this is a complete solution.
What about Set_CPU? And Delay_Until_And_Set_CPU? Those also should be checked.
Convert this to a Binding Interpretation.
Approve AI with changes: 7-0-1.
Steve Baird: Extra that: AARM Proof: 13.1.1 says that all operational attributes [that] can be specified with an aspect_specification.
Tucker notes that the old wording says “may” and the new wording says “can”. Both should be “may” in 13.13.2(38/2).
In the summary replace the second sentence, “Class-wide attributes for interfaces can be specified as any nonabstract subprogram.”
In the real wording, replace “stream attribute” with “stream-oriented attribute”.
Jeff notes that stream-oriented attributes aren't in the index.
Approve AI with changes: 7-0-1.
The problem is not at all compelling. AI12-0124-1 directly addresses the example given in the problem statement, so it's even less compelling with the Corrigendum features in place.
Moreover, there are many pitfalls.
Hold AI: 8-0-0.
The wording should start with “X'Image denotes...” to be consistent with the other attributes.
Put each after the matching subtype version.
Change to Binding Interpretation.
Approve AI with changes: 8-0-0.
Erhard wonders whether we should make all of the attributes that might make sense using an object prefix. It only makes sense for attributes that have one argument of the subtype. For instance, Value doesn't work because the parameter (which would be the prefix) is String, not the result type. So it only makes sense for Pos, Succ, and Pred.
Tucker thinks that as procedures these should be Inc and Dec. And then as an amendment for future.
Not in corrigendum: 7-0-1.
Protected functions/procedures are not potentially blocking (formally), that's not changing here. All this does is revoke the permission to execute functions in parallel.
Steve wonders if callers need to know about this aspect (as in synchronized interfaces). The callee does all of the locking (at least officially).
Tucker suggests that we want a Not withstanding rule as an Implementation Requirement. He suggests that we might even consider putting it into Systems Programming Annex. Probably as C.8, “protected object locking”.
Steve Baird will take this AI and produce wording.
This is a Boolean aspect Exclusive_Functions. “Mutually_Exclusive_Functions” would be better, but it's awfully long. So just follow the proposal.
Can this be specified on a derived type? No, that sounds like work (we'd need a new body with different locking). So don't allow on a derived type.
Tucker suggests that it is an aspect of a protected unit. (Like Pure.)
Approve intent: 7-0-0.
We spend a lot of time looking at the meaning of the various I/O packages, in particular if buffering is allowed. All of the Read and Write routines only talk about the internal file. So it appears that buffering is allowed (at least in the underlying OS). So it makes sense to have Flush for all packages.
Jeff suggests defining Flush in A.8.2 as it currently is in A.12.1, and then referring to the A.8.2 version in A.12.1. That makes a lot of sense.
The Text_IO version has to stay where it is as it refers to Current_Output.
Make this a Binding Interpretation, and trust the editor to get it right.
Approve AI with changes: 7-0-1.
Jeff: “corrsponding” in the summary. 3rd paragraph of question: “evaluared”.
In second line of the discussion, “the the”.
Pre'Class is not defined to be True if anything is inherited (see 6.1.1(3/3)). So we don't need the extra wording in the Dynamic Semantics.
Typo in discussion: “substitutability” is missing a 't'.
Steve notes that the Legality Rule should have the generic boilerplate.
Drop the editor's note (we've covered that).
The “optional” legality rule is required. Otherwise, we would have an inconsistency rather than an incompatibility.
Drop the paragraph about possibly making it a suppressible error, and all of the wording about it being optional.
Update the ACATS test section to reflect the legality rule.
Discussion: Thus we say that [a] overriding a subprogram that has no Pre'Class specified {for any ancestor} causes the new subprogram to inherit a Pre'Class of True.
Approve AI with changes: 6-0-2.
“a example” in the question.
The wording needs to start with the “At the place”. No, this is directly a freezing thing, and should go higher.
Note that 13.14(10.2/3) is also out of place, but we surely aren't going to change that in this AI.
Gary says it belongs in the list of bullets 13.14(4-7.2). Tucker says after 13.14(6). [Later, we moved it to after 13.14(5/3), see the discussion of AI12-0103-1 – this AI was discussed first.]
In the discussion, change “may be” to something more positive (we think the problem didn't occur in Ada 95).
Drop the sentence about convention.
Approve AI with changes: 7-0-0.
Default initialization is not “visible” if the partial view has unknown discriminants, so a check is not needed nor expected. So we ought to except that from the wording.
We're not going to do anything for uses inside the package for types that don't have unknown discriminants, as such types can be default-initialized both inside and outside of the package, and they ought to work the same in both places. As such, in a correct program, the check inside the unit cannot fail.
Randy will rewrite the discussion.
There ought to be an ACATS test specifically to check that a type with unknown discriminants does not get an invariant check on default initialization.
Change the comma at the end of the wording to a semicolon.
Approve AI with changes: 8-0-0.
The 'M' in More should be in lower case in the subject.
Tucker says the best fix is to allow arbitrary expressions of discriminants. Steve notes that the problem is that we don't want to evaluate these such that different objects get different answers for the same discriminant value (as in D+Func, where D is a discriminant and Func is a function call) [Or worse, the same object at different times even when the discriminant didn't change.] We'd need a fairly complex rule to only allow cases that are safe (something with complexity similar to “predicate static”. No one is that excited about that.
Erhard would like someone on the ARG to compile all of the examples. Seems like a good idea, he is given an action item to do that.
Change the subject to fix the example, since there is only one presentation error in this AI.
Approve AI with changes: 7-0-1.
C doesn't define the size of enumerations. But that's OK, we certainly want the Ada compiler to match the target compiler.
Steve Baird wonders what the corresponding type in C is for a record type. (For instance.) We have rules for parameter passing but nothing to define corresponding. This idea doesn't get much traction.
B.1 should say that enumeration types are eligible for convention-C.
Should we allow other types? (Modular, fixed, float are discussed). Most of these have no direct counterpart on the C-side. Float is already handled in the package Interfaces.C. So don't go further.
This change seems to imply support for Fortran and Cobol as well. That's OK if there is no corresponding type, it doesn't mean anything, and otherwise, it should work.
What about enumeration representation clauses? C has something similar, so it makes sense to allow them. So no special wording is needed for that.
Tucker will take this AI and create wording.
Approve intent of AI: 7-0-1.
Randy explains that the problem is what (if anything) the user can rely on.
Tucker would like it to be implementation-defined whether a language-defined generic unit does allocations from the default storage pool.
“might or might not”
Tucker suddenly thinks that is weird. So he suggests putting it after 13.11(20).
Tucker believes that there is no new problem for use of a pool in a language-defined package; 13.11(21) seems sufficient.
Randy is directed to create a new AI to handle the erroneous execution issue for Allocate_From_Subpool. Probably should just say that the same requirements as outlined in 13.11 need to be followed, otherwise execution is erroneous.
Randy will rewrite the discussion to match this conclusion.
Approve AI with changes: 7-0-1.
“ apply to” in the summary “applies to”.
Tucker suggests “given an access type whose designated type is T or T'Class, where T is an incomplete view...” in paragraph 2.2. Also “...has {an}[this] incomplete view except when:”.
Then at the end paragraph 2.6 “view of T or T'Class”.
Randy notes that there is no incomplete view of T'Class.
Tucker thinks that we need some rule after paragraph 2.1 instead of the above.
Steve Baird suggests “For an incomplete tagged type, the class-wide type is also incomplete.”
“If T denotes a tagged incomplete view, then T'Class denotes a tagged incomplete view.”
In the question, “a class-wide type has no {explicit} declaration...”
The editor will redo the discussion.
Approve AI with changes: 7-0-1.
Tucker would prefer that the term was “immutable”.
We don't want to make inheriting discriminants illegal. We shouldn't have to say anything, because the discriminant still exists.
Wording: “the the”.
The Boolean aspects should not be involved, they don't have this problem (they already have rules to prevent it). Leave 13.1.1(34/3) alone.
Ugh. Steve will try to reword this overnight. We definitely have to be careful so that the aspect can be specified for a non-root type if there is no specified value beforehand.
“confirming” is not defined for operational aspects. So we don't want to use that in wording, but something like that would be nice.
Iterator_Element should be included in the list of aspects.
The list of aspects is weird, that should be mentioned for each aspect at their place of declaration. The existing rule should be left but put in square brackets.
“The <blah> aspect is immutable (see 13.1.1).” (or the plural form, “The <blah> and <bletch> aspects are immutable.”).
In the 13.1.1(34/3) redundant list, drop “defined to be”, just use “are immutable”.
Typo: period in that list rather than comma.
Very last paragraph of this wording, “Implict_Dereference” aspect.
Needs to say “discriminated or tagged”, as it would be possible to add discriminants to an extension and then specify Implicit_Dereference. The type then could have two implicit_dereferences in some visibility locations, which would clearly be madness.
That makes better sense, it's more general. But it won't work for values, we won't worry about that as we don't have any such aspects now.
13.1.1: “...then an[y] explicit specification...”
13.1.1: “Redundant[The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing aspects are defined to be immutable.]”
type Parent is tagged null record;
type Child (D : access Integer) is new Parent with null record
with Implicit_Dereference => D;
type Priv is Parent with private;
private
type Priv is Child with null record;
-- Priv has hidden Implicit_Dereference.
Priv does not visibly have Implicit_Dereference.
This happens for all of the cases, so we have to replace all of the wording.
Give this back to Steve to redo this wording.
Approve intent of AI: 7-0-1.
The subject is backwards. Randy needs to explain why the RM wording doesn't work; he ran out of time to reconstruct that description.
We'll defer this one until he does that.