The meeting convened on Friday, 15 November 2013 at 13:40 hours and adjourned
at 12:15 hours on Sunday, 17 November 2013. The meeting was held in the Boardroom
at the Wyndham University Center in the Oakland neighborhood of
Pittsburgh, Pennsylvania. The meeting covered all of the normal AIs
and some amendment AIs on the agenda.

Approve minutes. 9-0-1.
[Editor's note: In posting these final minutes, I noticed that the
year was wrong (2012 instead of 2013) in the meeting summary.]

Date and Venue of the Next Meeting

The next meeting will
follow the Ada-Europe conference in Paris. That will be the afternoon
of June 27th (WG 9 has Friday morning as usual), all day
on June 28th, and the morning of June 29th.
The venue is TBD, as the conference venue may not be available on the
weekend.

Thanks

Thanks to the editor (Randy Brukardt) for taking the minutes.

Thanks to HILT and SIGAda for the excellent arrangements.

Thanks to the Rapporteur (Jeff Cousins) for his efforts to lead us.

ARG Procedures

We made a number of primarily editorial changes, listed in the e-mail of
November 12th. There were enough such changes that it seemed
reasonable to re-approve these procedures.

Erhard comments that the second sentence under Promising and Hold is
overspecification. We could use these statuses even during a revision for
things that we don't want in the current revision but might want to reconsider.
Or for AIs that we don't know what to do with (we've had a few of these
in the past). So delete the two sentences (“This status is
used...”).

Approve procedures with changes: 8-0-2.

ASIS

WG 9 has put the work on ASIS on indefinite hold. The main reason for
creating a standard is to encourage portability between implementations. But
there is little evidence of demand to port ASIS applications; most are
constructed for a single implementation and never moved. We also need
more implementer input into any Standard update that we might
propose, but today they aren't very interested in the formal standard
preferring to add facilities as they need them informally.

As such, WG 9 believes that we need to wait for user demand for more
portability and a standard. There isn't enough user demand today to encourage
the implementers to follow a Standard even if we constructed it.

Parallel Processing

Steve Michell gives us a WG 9 recap. Canada had proposed a formal parallelism
study group for SC 22, but that did not go anywhere. Various languages have
proposals. Specifically, OpenMP – which has various language
interfaces; CILK. C wants to put parallelism into the language (CPLEX).

Canada is concerned that these approaches will interfere with each other,
making multilingual programming very difficult. SC 22 didn't agree.

The subcommittee is working on proposals for Ada. They think that just
having work distribution mechanisms isn't enough, we also need mechanisms that
real-time people can use.

Steve Michell suggests that we would use aspects to specify parallelism. That
would require extending aspects to work on statements. [Editor's note: Since
aspects are properties of entities, and a statement is not an entity,
that would be quite an earthquake. Probably it would be best to use a
similar syntax to specify these things, but avoid calling them aspects.]

Brad has been working on parallel libraries for Ada (known as Paraffin).
These are available on Soureforge (http://paraffin.sourceforge.net/).

Tucker notes that the first step probably should be an API for OpenMP or the
like.

Ed notes this is two tasks: one is features for Ada; the other is outreach
with other languages. Tucker doesn't think we want to separate those much.

Jeff asks that links to the papers and Brad's SourceForge be passed around to
the ARG.

Steve Michell notes that machines are moving beyond cache-coherent systems
to “networks on a chip”. The subcommittee is trying to look
forward to future architectures as well as current ones.

Tucker notes that it would be nice to support atomic operations (possibly
defined in terms of protected operations), like compare-and-swap. Geert notes
that GNAT compiles appropriate protected objects into that.

Old Action Items

Steve Baird says that the paper for
AI12-0016-1
is going to be done “someday”. He also hasn't recently worked on
AI12-0020-1
(an Amendment), he doesn't think there is a rush.

Brad Moore says that he was too busy to work on
AI12-0031-1
(and he forgot that he needed to do so). He says that he'll try to finish it
tonight (which he did, see AI12-0031-1 discussion below).

Ed Schonberg has no explanation for not working on
AI12-0002-1 (he explained it as “a
dog ate my homework”!). Van Snyder isn't available right now,
so that was his excuse for not working on
AI12-0058-1 (also with
Tucker Taft).

Tucker Taft says that he was overwhelmed with work related to being the
Program Chair for the HILT conference. It was such a burden that he signed up
to do it again next year! Anyway, he updated
AI12-0071-1
last night (Thursday), so we can discuss that during the meeting even though it
was left off of the agenda since it wasn't done by the deadline. He
says that he will try to do
AI12-0068-1
tonight (Friday) -- but he worked on meeting assignments rather than that AI on
Friday and Saturday nights.

Randy notes that a number of people didn't do their ACATS test homework by
the deadline of September 30. Those can be added to the Ada 2012 ACATS even after
its initial release, so those items will remain on the action item
list.

New Action Items

The combined unfinished old action items and new action items from the meeting
are shown below.

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 2 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 immediate scope of a pragma {when not used}[which is not used] as
a configuration pragma ...”

Bob would prefer to give a name to the standard storage pool.

That doesn't seem any simpler than this; we'd need a package and come up with
a name for both the package and pool.

Randy suggests that we could use an “identifier specific to a
pragma” in pragma Default_Storage_Pool, rather than defining a new, similar
pragma. Randy notes that null already is playing this role in the
pragma, we just need another such name. No other reserved word seems
appropriate. Tucker suggests “Standard”. This is a third
way to do this (the way it is written up is one, Bob's standard pool
object is another, this is a third).

Tucker suggests using Standard (as in package Standard) so that it could not
possibly conflict with a user-defined pool name. It seems weird to allow a
package name in this pragma, but probably not any weirder than an identifier
specific to a pragma.

Bob says this is just a less capable way to doing what he is suggesting.
That's intentional; Steve notes that the default storage pool is a strategy, not
necessarily a pool object.

We agree that this needs to be changed to use a special name (either as Tucker
suggested, or just as an identifier specific to a pragma).

Brad will take this one.

Approve intent of AI: 6-1-0. Bob is still opposed as he thinks a real object
would be better.

Tucker notes in passing that a standard storage pool object could not be
defined in a pure or preelaborated package as it is a variable. That would
restrict its usage (especially in preelaborated packages). The special name
approach does not have that problem.

[Editor's note: This is not quite right. I think I recorded Tucker's comment
correctly, as we talked specifically about how that's not much of a limitation for
pure packages (which can't declare non-local access types anyway). As
such, it's only interesting for preelaborable packages. However, a
preelaborabable package can have a variable so long as the type of that variable
has preelaborable initialization. Since Root_Storage_Pool does have that kind of
initialization, it's possible to have a storage pool variable in a preelaborated
package. But I don't think we would want to insist that the standard storage pool
has preelaborable initialization; such types typically need complex
initialization that's unlikely to be preelaborable. In any case, it's
not quite as clear cut as the comment above suggests.]

[Unrelated editor's note: By making this an identifier specific to a pragma,
this AI could (and should, IMHO) become a Binding Interpretation. Brad ought
to consider that and possibly rewrite the AI in the form of a BI.]

We agreed that local calls would not use the PCS. The problem is that
access-to-subprogram don't know whether it is local or not, as that depends on
both the target of the call and the location of the call. Option 1, all such
calls are direct (not through PCS). Option 2, all such calls should
be though the PCS.

All_Calls_Remote is for debugging the system when the system isn't really
partitioned. So it is only important that calls that could be partitioned
be remote; not ones that could never be remote.

For a remote access-to-subprogram type, that should be a remote call. But Bob
points out that the runtime could bypass the PCS if the partition id
is the same for the caller and callee. That runtime optimization has
to be turned off when All_Calls_Remote is set; that's true for any
sort of remote call (so this is not a new issue). For a normal (not
remote) access-to-subprogram, then it is a local call (no use of
PCS). It has nothing to do with the designated subprogram.

All_Calls_Remote prevents any optimization (compile-time or runtime) of remote
calls, and ensures direct calls that could be remote are remote.

Steve asks about remote dispatching calls (thru remote-access-to-class-wide).
They also should have optimization prevented.

Remote subprogram calls are defined in E.4. Probably should have a (see E.4)
for that. (ultimately, we decided to effectively copy the definition instead).

E.2.3(19/3): Tucker thinks the wording is still unclear. Try instead

If aspect All_Calls_Remote is True for a given RCI
library unit, then the implementation shall route any of the following calls
through the Partition Communication Subsystem (PCS); see E.5:

A direct call to a subprogram of the RCI unit from outside the
declarative region of the unit;

An indirect call through a remote access-to-subprogram type;

An dispatching call with a controlling operand designated by a value
of a remote access-to-class-wide type.

Other calls are defined to be local and shall not go
through the PCS.

Redo AARM note: 19.b:

There is no point to force local {direct} calls
({including}[or] calls from children) to go through the PCS, since on the target
system[,] these calls are always local, and all the units are in the same active
partition.

{However, i}ndirect and dispatching calls {through remote
access values} [however] go through the PCS because the extra complications
in determining whether the {caller}[denoted subprogram] is local to
the All_Calls_Remote RCI unit was deemed to be [too] excessive.

!discussion

The goal of the All_Calls_Remote aspect is to force calls
from outside the declarative region of the RCI unit to go through the PCS.
Calls that are local to the {RCI unit}[PCS] should always be local
and never go through the PCS.

This ideal [is] can be implemented easily enough for direct
calls, but there are excessive complications for the case of indirect or
dispatching calls. In particular, it would be difficult for the
implementation to determine whether {a call}[if a remote
access-to-subprogram value or a remote access-to-class-wide type
value denoted a subprogram that] was local to the RCI unit, and thus
whether the call should go through the PCS.

Bob thinks that its silly for both the discussion and the AARM to say the
same thing. Drop the second sentence of AARM 19.b.

After discussing some other topic, we return to the wording of E.2.3.(19),
which Randy e-mailed.

Tucker thinks the wording is still unclear. It is revised to:

If aspect All_Calls_Remote is True for a given RCI library unit, then
the implementation shall route any of the following calls through the
Partition Communication Subsystem (PCS); see E.5:

A direct call to a subprogram of the RCI unit from outside the
declarative region of the unit;

An indirect call through a {value of a} remote access-to-subprogram
type;

An dispatching call with a controlling operand designated by a value
of a remote access-to-class-wide type.

Other calls are defined to be local and shall not go
through the PCS.

Tucker notes that the
rule should only apply to designated subprograms from the
All_Calls_Remote unit.

An indirect call through a remote access-to-subprogram [type]{value
that designates a subprogram of the RCI unit};

An dispatching call with a controlling operand designated by [a
value of] a remote access-to-class-wide [type]{value whose tag
identifies a type declared in the RCI unit}.

Drop the “other calls” sentence. It is not true without
qualification, which we don't want to have. (Calls to other RCI units have to be
remote, even if All_Calls_Remote does not apply to them.)

Randy suggests simplifying the recommendation and using it as the summary,
since it explains the problem in two sentences. The recommendation then
becomes “see summary.”

Randy mailed the entire wording section of the AI. There is a glitch in the
E.2.3(19): “A[n] dispatching...”

We need an additional rule to prevent tagged ancestors from being used as
actuals for untagged derived formal types. Tucker wonders if the category already
requires that. Randy notes that 12.5.1(1) defines the category, and
it allows this case. So we need a rule.

Ed reports that GNAT compiles this program without complaint, which isn't
going to work.

Tucker thinks that the reverse problem is possible. He shows an example:

Randy notes that the dynamic rules already work so there is no wording other
than allowing them.

Steve wonders about null procedures being inherited from multiple types, but Randy
believes that we already have (and solved) such problems. [The new
rule of AI12-0042-1 (7.3.2(6.1/4)) should eliminate any
problems by making inheritance illegal in that case.]

The original issue was Type_Invariant'Class inherited into record extensions
(with visible components). A similar issue was identified for adding invariants to
private extensions of record types (with visible components). In both
of these cases, privacy could be broken such that the invariant would
not hold after a change (that is, in such cases, the places where
invariants are checked are insufficient to prevent problems). We decided
its not worth preventing such things, even with the possibility of misuse. The
above should be added to the start of the discussion.

The problem that is being solved occurs when private operations are inherited
visibly. Tucker says that replacing “inherited” with “visible”
(at the point of the declaration) is necessary. Steve worries about
other declarations; Tucker points out that this is “visible”,
not “directly visible”.

Tucker does not believe this is the best way to describe this. Dynamically
callable is the bad idea. He thinks that the issue is the nearest ancestor that
is in a visible package specification with a private part (and therefore
could have invariants). He claims that this rule was only for
specific invariants; Randy disagrees, he thinks this latter part was
added for these sorts of cases (specifically, ones like T2).

We can't convince Tucker that the wording is good enough. He wins the chance
to rewrite this.

We agree on the intent that checks (all invariant checks) are made in cases
like this, but we haven't agreed on how to describe this formally.

Steve makes comment (1), Tucker replies with comment (2). Thus there is not
a problem.

If T2 is with record, then it's visibility is not considered. So again
there is no problem.

Tucker does worry that “visible” is too ambiguous. He doesn't
have a suggestion.

Randy worries that this definition means that new primitive operations of a
record extension are not checked against an inherited class-wide type invariant.
If the programmer later derives a private extension from that type, the
operation would suddenly get checking. That's similar to the private
case where we require overriding. Tucker claims that there is no
issue, since there is no privacy breaking going on in this case. [Editor's
note: He's since been convinced that there is an issue, and this AI has
been reopened to address it.]

In the discussion, get rid of the history. “This AI discusses two
issues...”

The ACATS test should include C-Tests.

Tucker will update this during the break.

During the discussion of AI12-0059-1, Tucker asks if
“visible outside of the immediate scope of type T” is sufficient.
This is previous wording used elsewhere.

Tucker will e-mail this, because it's too hard to figure out what he's
talking about.

Geert wonders why we don't require concurrent reads. We don't know whether
an in mode parameter is only read or whether it might be written (if it
is a handle, for instance, like many of the File_Type operations in Text_IO).
Going through the Standard to figure that out on a case-by-case basis would be
a massive amount of work of dubious value. This is a weak requirement added
because Ada 83 vendors sometimes did preposterous things (like using global
variables in Calendar). Vendors certainly are allowed to go further.

Erhard worries that access parameters aren't properly handled here. They're
by copy, and they could have the same value (designating the same object). That
can't be expected to work. This applies to stream operations, for instance.
That has been wrong since Ada 95, and there is some sentiment not to fix it at
all. Erhard is asked to create an AI to explore/fix this issue.

Typo in the AARM note for A.10.3(21): “...with the file give{n} to
the...”

This was defined in such a way that is incompatible with the existing
semantics in the standard. That seems to be a problem; we just wanted the
existing text defined with semantics. Certainly, we don't want to change the
semantics in the absence of a bug, that would require an Amendment.
[Editor's note: We do need to make clear that the Ravenscar rules
have the potential to practically invalidate the rules about
scheduling such as FIFO_within_Priorities, because CPU assignments
override those.]

So we want a pragma to codify the current extra rules. Possible names suggested
include No_Task_Migration or Static_Task_Assignment. We do not decide on a
name for the pragma.

The AI should be split. D.13(8/3) should be defined as a pragma (possibly
with one of the names suggested previously) which is part of the Ravenscar
profile, as above, and then a new AI with additional pragmas that aren't
implied by Ravenscar (as defined in the existing AI).

Geert will take these AIs.

Keep Alive: 9-1-0. Bob votes against; he does not think making into pragmas
is important enough, and he's not convinced that new functionality is needed.

Geert says that having these pragmas would benefit compiler-writers for
testing.

Randy provided the last version of
AI95-0319-1,
which he had updated with the comments from the last time it was considered,
even though it was killed at that meeting. This was killed mainly because of
opposition from Rational, they didn't like it participating in static matching.

“...choose for a stand-alone aliased {variable}[object] of subtype S.”
One can imagine constants taking advantage of discriminants not changing.

Here we had a break and then discussed some other AIs. We then returned to 59.

There is a discussion as to whether this is well-defined when not specified.
Tucker is convinced that there is a unique value for non-limited aliased
variables. Steve disagrees. Steve and Tucker will take this off-line.

Randy asks whether we want to make these always subtype-specifiable. The
consensus is yes. Remove all of the implementation-defined stuff about that.

Randy wonders whether this should be mainly defined as an aspect. Leave it
described as an attribute, as this will be next to Size and it would look weird to
talk only about aspects in a list of attributes.

Ed announces he just got an alert that his flight is canceled, and after some
disruption (caused by many people checking and/or rebooking their flights), Ed
and Geert leave to go immediately to the airport to catch alternative
flights. (This discussion occurred relatively late on the last day of
the meeting.)

Back to the AI. Steve worries that there isn't a unique value in some cases.
We will make such cases implementation-defined. We need to say that the value for
limited types is implementation-defined. [Steve didn't explain what
other cases are involved.]

We talk about the nominal subtype of the
loop_parameter. This is not
well-defined for for loops, either. Steve would like to propose that
there is an implicit static predicate. That seems like overkill. Instead, we
should just use First_Valid to Last_Valid (if the bounds are static).
There is no mention of predicate. Tucker would like to add the
predicate, or use the index subtype.

It's much easier to just use index subtype. Using a case expression inside of
an aggregate is not very likely (it would be better to distribute the
choices). [Editor's note: But using a case statement inside of a for
loop is more likely, and we would expect to use the same definition
for those. I hope!]

parameterized_array_component_association,
would better as iterated_component_association,
even though it doesn't iterate in any particular order.

Erhard wonders why this is a choice rather than just a kind of an aggregate.
Allowing only one of something when there isn't a lot of extra work to allow many
is a bad idea. Compilers already have to deal with static
discontiguous aggregate choices, and this is defined similarly, so
this shouldn't be a major disruption to compilers.

In the AARM example, T3 is visibly derived (indirectly) from Integer, but it
doesn't have numeric characteristics. “this situation” should be
explained better. Explain which is the ancestor, and the descendant.

At least part of the formal text of 7.3.1(5.2/3) is not redundant. Erhard
wonders about the type conversion rule that allows to convert to your grandparent's
type. He doesn't find it clear as to what allows that.

Tucker says that Gary has convinced him that the first sentence of 7.3.1(5.2/3)
is broken. He thinks the first sentence essentially says that an A is not an A.

The “{Furthermore,
it} is“ is missing the closing insertion bracket, which
belongs as shown here.

ACATS: No additional tests are needed.

Drop the TBD from !wording.

This should be a !ramification rather than a !binding interpretation, because
it makes no language change.

We discuss that T3 would match a formal derived (type T is new Integer). The
characteristics “exist” but are never visible, but they
can emerge inside a generic. We had a case like this for equality
previously. Steve notes with wonder that while T3 would not match a
formal integer type, it would match a formal derived, and that would
match a formal integer type.

Erhard wonders about the idea of progenitor subtypes. These are the subtypes
named for the progenitors of the declaration. But this isn't well-defined, we need
to add a bit of wording in 3.4.

Tucker notes that he (re)wrote these as “tests”, because they
are not necessarily part of a check (they could be part of a membership or
Valid).

Steve asks that the rule about evaluating the Predicate_Failure be marked as
redundant. Tucker argues that it is insufficiently obvious to be redundant.
Straw poll: Redundant: 1; Not redundant: 4.

Tucker will look for the cases where the terminology needs changing
(“BIG NOTE”).

Tucker worries about S'Base. It's not a first subtype. We throw away all of
the constraints (including those of parent), so we don't want it to have
any predicates, either. Even from the parent. Geert notes that S'Base
is used in generic elementary functions, and we don't want any
predicates to reappear there (or anywhere else).

So S'Base has no predicates. Tucker should craft a user note to this effect.

There is a question about the wording change for the Valid attribute. The rules for
Volatile do not allow the introduction of reads; thus we have to say that X'Valid
reads X so that it can be implemented. (How the value could be tested
without reading it from memory is hard to imagine.)

Approve intent of AI: 9-0-1.

Tucker will try to update the AI (including the summary and discussion).

Steve explains the sort of problems that can happen in the access cases.

The possible fixes are: (1) statically illegal (incompatible, there is an
easy workaround to the incompatability); (2) pass in null (which is inconsistent,
but even less likely to be noticeable); (3) make the type checks on input (also is
inconsistent).

Steve also notes that the static solution has the advantage of being the same
as scalars. It is also better to find out at compile time rather than at
run-time.

Straw vote: Statically illegal 8-3-1.

Bob argues for a warning, along with declaring this case erroneous (or
implementation-defined).

Bob points out that most subprograms do not read the object.

Steve will write this up as a statically illegal case.

Geert suggests that if this happens and we're allowing it (possibly via a
suppressible error, see the discussion of AI12-0092-1), it
should be defined to be abnormal. In that case, it would only be erroneous if
read, which is what we would want.

Why does D.16.1(16/3) describe these as a “series” of processors?
D.16.1(16/3) should say “set” rather than “series”. (That
really ought to have been done as part of
AI12-0033-1, but we can fix it here.)

The last two sentences of D.16.1(16/3) are confusing. (These were not touched
by this AI previously). Modify them as follows:

System_Dispatching_Domain {identifies a domain that} contains
the processor or processors on which the environment task executes. At
program start-up all processors are contained within {this
domain}[System_Dispatching_Domain].

The problem is that a mix-in generic can't be used if the type has extension
components and a constructor function.

Tucker had suggested that making the type abstract would allow a later
derivation. Steve says that doesn't work if the user needs to declare an object
in the generic. [Editor's note: It doesn't work very well if the generic type
has private extension components, as then it's not possible to write an
extension aggregate in any user-written constructor function. As such, an
explicit call on some sort of exported initialization procedure would have
to be used, which is error-prone.]

Randy tries to explain that he proposes here extending the concept of
automatic creation of constructor functions to types that have an aspect
specifying that their default initialization of extension components is
sufficient initialization. In that case, the same mechanism that currently
allows null extensions to automatically create constructors can be extended to
all types with that aspect. Randy notes that this would greatly reduce the
maintenance hazard related to that feature (his long-standing complaint about
the feature).

The group agrees that the problem is worth solving, but this solution isn't
well liked. The main complaint seems to be that the need to declare that default
initialization is sufficient seems unusual to most. It's necessary, of course,
to prevent problems when default initialization is not sufficient; perhaps it
would be better to have an aspect to declare that. (Such a solution would still
be compatible as this is a new capability either way.) We certainly would not
want to give up compile-time checking of constructors in the case where they
really do need to be written explicitly.

Since this problem has
existed in Ada since Ada 95, we think we need to see more evidence
that the problem is significant before we try to proceed to find a
solution.

Randy and Robert agreed on the meaning during the e-mail discussion. Randy
notes that Robert's argument about usability convinced him. Someone says that's
unusual, so this must be the correct answer. Someone else suggests
watching out for flying pigs [Editor's note: I hope it's not that
unusual that we agree!].

Randy notes that the AI doesn't reflect this meaning. The AI wording should
be changed to drop the Redundant part. Add a AARM ramification to say that
overlong encodings are not considered invalid on input but never generated (it
does not depend on the character set standard).

Change the answer to the question. Change the summary.

The last sentence of the second paragraph of the discussion needs to be changed.

“You cannot optimize away a conversion from UTF-8 to UTF-8 because
there must be a check...”

Randy explains that John asked this question during his editorial review, and
it made him look over some of the wording to see if it made sense for generic
functions. This fixes some that clearly doesn't.

For 6.5, put a To Be Honest after 6.5(5.2/3) to say that “function”
also means “generic function”. This sort of follows from the fact
that a “function body” includes generic function bodies,
and the lead-in text thus includes generic functions. Thus the rest
of the text must also include generic functions. This could be a ramification.

6.5(4/3) only talks about callable constructs, and a generic function or
procedure is not a callable construct. Yuck. The To Be Honest needs to cover that.

Steve suggests that we have two options. One is that a requeue can't have any
postconditions. Alternatively, it can have a postcondition only if it
conforms (is the same), and it cannot contain 'Old.

Preconditions have to be evaluated on requeue. This is not a call, so we'll
need new wording to accomplish that.

There is no need to require the preconditions to be the same, just that both
get evaluated.

Ed asks what happens if the parameter names change on the requeue. Tucker
notes that there is a similar problem with class-wide preconditions
and postconditions. That should be a separate AI. Bob thinks this
isn't worth writing an AI for; Tucker and Steve think it's
necessary. Tucker will take this AI for class-wide preconditions and
postconditions. [Editor's note: Is there a similar problem with the
name representing the current instance in class-wide type invariants,
and with any inherited subtype predicate? Those also will have
different names than used in the assertion expression. Or is the fact
that it is the current instance enough? Perhaps this could be
addressed in AI12-0068-1.]

Steve volunteered to take this AI before the last question came up, and now
it's too late to back out.

Tucker brings up type invariants. What if an interface or a protected type
has a type invariant? It's possible to have an interface with an operation that
is implemented-by an entry. We can requeue on that. If we have a
private type that uses such an interface as a progenitor, then we can
have a type invariant that applies to an operation that we requeue
on. What are the rules for that? Steve will take this problem off-line.

Randy notes that the wording needs to allow requeuing on procedures that are
implemented by an entry. Steve gets various other comments on the wording. (He
says he made notes and that it wasn't necessary for the editor to
record them all – hope he's right because I didn't record them - Editor).

“aforementioned” is bad as the text is 5 paragraphs. Say something
else.

Back to invariants. A type invariant that applies to (the type of) E1 has to
apply to (the type of) E2. Tucker says that the parameters have to have the same
subtype, so we don't have to worry about invariants for parameters.
Randy notes that E2 doesn't need to have parameters. If the
invariants are implemented in the body (someone confirms this is how
GNAT implements invariants), how does that work?

Geert says that having the instruction isn't relevant, the issue is more that
the argument reduction would be shared, and argument reduction is expensive. GCC
actually recognizes cases like this, so there is no need for an
additional routine in GNAT.

This is an optimization that compilers can do. Tucker thinks this is a
slippery slope, in there are many other combinations that make sense and often
appear together. We don't want to open a large can of worms.

Erhard says that users won't believe that optimization happens. He thinks
that common machine instructions should have first-class interfaces.

Geert says that an AARM note that argument reduction should be done only once
would be appropriate. But in which cases?

If we have this, we should have a Cycle version. Jeff would like to take this
AI and provide wording.

Do other languages provide this? It's not in the C or C++ standards now, but
that might change in 5 years. It is in some C implementations (GCC C, Visual
Studio).

Tucker worries about the criteria for choosing between a Soft Error vs. a
Hard Error. Bob primarily plans this be for a compatibility issues. Tucker does
not like coming to a language and seeing stuff specifically for
compatibility checks. He doesn't want to see the line between old and new stuff.

Erhard tries to give a more general definition for soft errors. It confuses
everyone, including the note takers. [Editor's note: I think he meant a
definition something like the following, but this is mostly my invention:
“A soft error is used when the compiler can detect a dubious construct,
but the construct can have a legitimate use in limited circumstances.”]

Bob had suggested that compilers would have a mode where soft errors would
reject the program. ACATS would include tests that would require that (as well
as test what happens when the error is suppressed).

Steve worries that having soft errors would make it necessary to go back in
the standard and find cases were we can statically detect bad code. That seems
like a can of worms. (for instance, Pos := -1;) Bob says that we
aren't required to do that.

Tucker suggests identifying errors as how new they are. He suggests that it
would be sort of like Suppress, where certain errors would could be ignored by
a compiler. It could be controlled by a configuration pragma.

Brad suggests that we call those suppressible errors.

What is the granularity of this? This would just be a global setting, mainly
for those who can't modify the source. If they can modify the source, they should
get rid of the bug, not suppress the error, so local control (like
pragma Suppress) isn't needed.

Tucker thinks that the First and Next are functions, so that the idea of an
indefinite cursor works, with a separate object.

Steve worries that Next takes the previous cursor as a parameter; so
we need to have the object last that long. So we effectively need two objects to
exist at the point at the call to Next.

You could use a Holder to work around the problem (wrap the indefinite type
in a Holder container, then use the Holder type as the cursor type).

We think that fixing this would be insane because of the need for two objects.
Thus, we will leave the semantics as they are, especially as the workaround is
easy.

No action: 9-1-1.

Randy and Steve note that we need an AARM note to say that the accessibility
of the loop object is that of of the loop statement, so the object is finalized
when the loop is left. Secondly, the object is constrained by its initial value
if the cursor type is indefinite. Steve says that the tag if it is class-wide
has to be covered. Tucker says that you can't ever change the tag of an object
during its lifetime. This object is a variable with a constant view.

We think this is OK.
Bob Duff will take the AI. He ought to check that declarative region
is not used in any way that would cause problems with static
accessibility checks.

Does this apply to named access-to-subprogram declarations as well? Steve
worries about the current instance of the type in the declaration (if it had the
same name as one of the parameters). Tucker says that would just be
hidden, it's not a problem. Tucker thinks that it is more natural for
this to be a declarative region, it's probably more work for a
compiler to make it not one. Randy recalls some Ada 83 ACATS tests with this
effect.

We'll try to make both named and anonymous access types work the same. That
seems more natural.

What about use of the parameter names in default expressions? An example is
shown:

Someone suggests that hidden from visibility rule saves us here. 8.3(16) says
that declarations (the parameters here) are not visible until the end of
the declaration, but that is the ending semicolon. It's not clear that's the
right rule.

6.1(21) says that you can't use a parameter name in the same
formal_part. But that allows the parameters
to be used in the result part. Until we added anonymous access-to-subprogram,
that wasn't a possibility anyway. But now it is, for example:

We probably need to change 6.1(21) to say profile rather than
formal_part.

We ask Bob to summarize the intent of the AI. He says that
access_to_subprogram_definition
is a declarative region. Randy notes that you also need to say
access_definition is a
declarative region. Steve says that it could be “the profile of
an access_definition and
access_to_subprogram_definition”.
We worry about that wording making sense in the anonymous
access-to-object case (which is syntactically part of
access_definition). Tucker
thinks it is harmless to have that. Returning to the intent of the
AI, Bob is going to fix 6.1(21) to say profile or something like that.