ARG Telephone Meeting, January 28, 2015 (Meeting 52A)

Attendees: Steve Baird, Randy Brukardt, Jeff Cousins, Robert Dewar (first hour and last hour), Gary Dismukes, Bob Duff, Brad Moore, Jean-Pierre Rosen, Ed Schonberg, Tucker Taft.

The meeting convened at 12:05 hours on Wednesday, 28 January 2015 and adjourned at 15:10 hours. The meeting covered the bulk of the agenda.

AI12-0146-1/01 Should say stream-oriented attribute (10-0-0)
AI12-0149-1/01 Type invariants are checked for functions access-to-T (9-0-1)

AI12-0142-1/08 Default storage pool for storage pools (8-0-1)
AI12-0141-1/01 Type_Invariant'Class for interface types (10-0-0)
AI12-0142-1/01 Bad subpool implementations (9-0-0)
AI12-0145-1/01 Pool_of_Subpool returns null when called too early (9-0-1)
AI12-0147-1/01 Expression functions can be declared in a protected_body (10-0-0)
AI12-0148-1/02 Dangling references (10-0-0)
AI12-0150-1/01 Class-wide type invariants and statically bound calls (9-0-1)

AI12-0129-1/01 Make protected objects more protecting (10-0-0)
AI12-0138-1/01 Iterators of formal derived types (7-0-2)

AI12-0135-1/02 Enumeration types should be eligible for convention C

AI12-0086-1/02 Aggregates and variant parts (9-0-1)
AI12-0143-1/01 Using an entry index of a family in a precondition (9-0-0)

At the end of the meeting, we determined that we did need another, shorter call to finish up AIs for the Corrigendum. (There are two AIs that need rewriting, and three that we didn't discuss.)

Jeff and Jean-Pierre say that February 25^th is bad for them. We decide on February 26^th, noon eastern time.

The editor notes that there are (at least) two AIs that don't appear on anyone's homework list, and do not have a wording proposal. Tucker agrees to continue working on AI12-0079-1 (Global aspect) and Brad agrees to continue working on AI12-0119-1 (Parallel operations). It would help to see wording proposals for these (the devil is likely to be in the details for these ideas).

The combined unfinished old action items and new action items from the meeting are shown below. (* indicates an AI that we'd like 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.)

Steve Baird:

AI12-0016-1
AI12-0020-1
AI12-0129-1*
AI for blanket rule for default for Boolean aspects (see discussion of AI12-0129-1)*?

Erhard Ploedereder:

Compile all of the examples in the Standard (see discussion of AI12-0134-1) and report on any difficulties.*
If possible, acquire some examples where Ada containers are too slow compared to other containers (for AI12-0111-1?).

Ed Schonberg:

AI12-0002-1?
AI12-0058-1? (with Van Snyder and Tucker Taft)
AI12-0112-1 (with Randy Brukardt)

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 5 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.

Tucker thinks that this wording is a mess. Tucker is still in favor of a check, for direct visibility only.

Jean-Pierre says that he thinks it is not important enough to make a check. Robert says that there are 22 uses of things called “Standard” in their test suite, so it's not that uncommon.

Randy suggests eliminating the 13.11.3(6.1/3) bullet and instead updating the “otherwise”. Tucker agrees with this change.

Remove Brad's discussion of why we didn't adopt the rule that we are adopting. Add an AARM note to say that use-visiblity isn't possible for Standard (it would always be hidden by the directly-visible package Standard).

[Editor's note: We're missing an aspect version of the rule against confusing Standard declarations. I added the following as a separate paragraph after 13.11.3(5/3):

Standard when used as the aspect_definition for the Default_Storage_Pool aspect is an identifier specific to an aspect (see 13.1.1) and does not denote any declaration. If the aspect_definition for the Default_Storage_Pool aspect is Standard, then there shall not be a declaration with defining identifier Standard that is immediately visible at the point of the aspect, other than package Standard itself.

Do we want this to be in the Corrigendum? There are no objections, so we don't take a separate vote, and just declare it as part of the Corrigendum.

Tucker shortened the wording amazingly. Steve says that “(selected)” is not redundant, and thus should not be in parens. Tucker says that he doesn't care. Drop the parens.

Steve says there is a problem with the wording. No_Return says that it defaults to False. We don't have that here, so we need to add it. (Copy the text from 6.5.1 for this one.)

Robert says that we should have a rule that says that all Boolean aspects default to False (unless otherwise specified); writing that all over the place is rather silly. That should be added to 13.1.1, and possibly the wording removed from all of the individual places it currently exists. Steve will create a separate AI to add such a blanket rule. Robert says that he checked all of the GNAT aspects and the language-defined ones, and they all default to False. Steve notes that the automatic use of True when the name is given in an aspect specification pretty much requires setting it to False by default. So a blanket rule makes sense. [Editor's note: but beware of the cases that gave trouble in the past, specifically Default_Value and Default_Component_Value where the type just happens to be Boolean. We don't want this new rule altering their behavior.]

Tucker is annoyed that this is a whole new subclause. It doesn't seem worth that. In any event, Tucker doesn't want this to be optional (it doesn't help if some compilers ignore it), so it can't go in Annex C. Why did we put it there at all? In Portland, some guy named Tucker Taft suggested that it goes there, and no one disagreed. Steve just followed the direction. Tucker says that must have been Tucker version 2.3, because he has no idea why he would have thought that was a good idea.

9.5.1(4) is the current rule that this aspect modified. It should be somewhere in there. Tucker says that since this is an aspect of the protected type, so it should go in 9.4. Steve notes that that would be a forward reference. So it does go into 9.5.1.

So it goes right after paragraph 2 (aspects typically are defined as Static Semantics), and the Dynamic Semantics part goes into paragraph 4. Something like “unless both actions are the result of a call on a protected function{ and aspect Exclusion_Functions is False for the type of the protected object}”.

Brad wonders if we should allow specifying it individually on functions (so some could be exclusive and some could not). It seems like a lot harder to do that, especially as internal calls could come into play. (You'd have to check the aspect for both functions to tell whether exclusion is required, and even then an internal call from a non-exclusive function to an exclusive function could cause trouble.) If you had a lot of functions in a protected type, it would add a lot of clutter. And it doesn't seem important. J-P says that we'd risk killing the whole idea with complexity; including where it is useful. We could always do that in the future if users demand it.

AI12-0135-1/02 Enumeration types should be eligible for convention C (Other AI versions)

Robert wonders how this gets mapped in COBOL. Tucker suggests that it get mapped into some integer type. For COBOL, that probably would be type Binary. Robert says that isn't consistently provided. Interfaces.COBOL has a type Binary, so the implementation better know how to map it to its supported implementation. If that's a problem, it's certainly not unique to this feature.

There hould be some wording as how the mapping is performed in B.3. After all, the original question was about portable usage of Convention C on enumerations .

Tucker says that this is not well-defined on the C side, and that could cause problem. Robert notes that C defines enumerations as Int, but on C++ allows enumerations to be smaller than Int. So the mapping might have to be different. The size is the problem.

Tucker will go back and say more about the C and C++ situation; we need to know how this maps. (Whatever is said will be Implementation Advice anyway, so it doesn't have to be perfect.)

The other rules are needed to avoid privacy-breaking. Gary would like some additional discussion – there's just an example and one has to figure out the problem for themselves The summary also needs a sentence saying that we need the rules to not be privacy breaking.

Tucker would like to try to factor out more of the common wording. Steve and Randy say that the rules aren't quite the same (Implicit_Dereference is different). Randy thinks it might be possible to factor out the rules involving with tagged partial views, but there might be trouble with conflicts (especially if one tries to word it in terms of what is allowed). Tucker still thinks that it can be done. He can put his pen where his mouth is, and try to reword this AI.

Jeff suggests making the change that the editor suggested to 57.15, but not the 57.18 change (he considers it unimportant). Tucker says the first is important, the second he has no opinion.

Ed suggests “(see 13.11 concerned with Erroneous Execution)”. Steve thinks that it is the definition, so it should not be parenthesized.

If Allocate_From_Subpool does not meet one or more of the requirements on the Allocate procedure as given in the Erroneous Execution rules of 13.11, then the program execution is erroneous.

The nominal subtype of this attribute is the entry index subtype.

We don't need to mention the type, since it “obviously” is the same as the type of the entry index subtype.

The requeue target shall not have an applicable specific or class-wide postcondition {that}[which] includes an Old {or Index} attribute_reference.

Other wordsmithing is considered, but Randy notes that we're looking at this out of context. So let's not do that.

Should this be in the Corrigendum? Ed says that it isn't that important. Bob would say to wait for a customer request before bothering to implement. Ed worries about the implementation cost; tasking stuff can be tricky. Jean-Pierre says that there is a name for it already in the body, so the implementation can't be that hard. Several people note that preconditions are not evaluated inside the body in general.

So it will remain an Amendment, status is Promising. [Editor's note: Actually, it was written up as an omission with a binding interpretation, so it really will become an Amendment.]

AI12-0147-1/01 Expression functions can be declared in a protected_body (Other AI versions)

We agree that null procedures and expression functions should be handled the same.

Randy asks about null procedures and expression functions in the spec. There might be effects on protected actions. It just doesn't seem worth any complications.

We discuss whether this should be in the Corrigendum. Randy argues that it was just an oversight that we didn't allow it. There is no possible semantic problem (these are equivalent to the full bodies according to 6.7 and 6.8, and of course the full bodies are allowed).

Bob says that we should allow this in bodies immediately as GNAT already supports this. It would be rather silly to suggest that their implementation is somehow wrong today when we plan to make it OK at some point in the future.

So this is in the Corrigendum (meaning it's a Binding Interpretation, which matches the current write-up).

Steve says that we don't need to talk about parts in the equality rule. The consequences could be in an AARM note.

Tucker suggests starting with:”it is a bounded error to evaluate an expression whose result is a dangling reference. Either Constraint_Error or Program_Error is raised, or in the case of predefined equality ..., execution proceeds normally.

Randy says that he doesn't want to try to do this himself, Tucker seems to know what he wants pretty clearly. So, Tucker will try to rewrite this part.

Later, we look at Tucker's new wording. Someone asks whether “might” is the normal way to describe a Bounded Error.

Randy looks up various Bounded Errors, and notes that most consequences start “If the error is detected...” In particular, the meaning of invalid values starts:

If the error is detected, either Constraint_Error or Program_Error is raised. Otherwise, execution ...

AI12-0149-1/01 Type invariants are checked for functions access-to-T (Other AI versions)

AI12-0150-1/02 Class-wide type invariants and statically bound calls (Other AI versions)

Tucker explains that this is similar wording to the precondition case. The main difference is that preconditions are on subprograms, while type invariants are on types. But the formal derived type model is the same. Ed notes that GNAT is literally using that model internally; it's declaring a class-wide precondition as a generic with a formal derived type which is then instantated for the actual type (each descendant type).

Typo in the example: function Proc (P : out Root)' should be procedure Proc (P : out Root);