Version 1.2 of ai05s/ai05-0240-1.txt

Unformatted version of ai05s/ai05-0240-1.txt version 1.2
Other versions for file ai05s/ai05-0240-1.txt

!standard 3.4(18/3)          11-03-02 AI05-0240-1/02
!standard 3.10.1(8/3)
!standard 3.10.2(13.1/2)
!standard 5.4(6)
!standard 6.2(11)
!standard 6.2(12)
!class presentation 11-02-04
!status Amendment 2012 11-02-04
!status ARG Approved 8-0-0 10-02-20
!status work item 11-02-04
!status received 10-09-16
!priority Medium
!difficulty Easy
!subject Rewordings from First Editorial Review
!summary
Change wording of existing approved AIs as suggested by various ARG members during the first editorial review of the draft standard.
!question
Some of the new wording in the standard is unnecessarily confusing. Should we improve it? (Yes.)
!recommendation
(See Summary.)
!wording
Change the first sentence of 3.4(18/3) [as modified by AI05-0164-1] to:
The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent or progenitor type, other than those subtypes found in the designated profile of an access_definition, with a corresponding subtype of the derived type. ...
Modify 3.10.1(8/3) [as modified by AI05-0151-1]:
* as the subtype_mark in an access_definition {for an access-to-object type};
Modify 3.10.1(13.2/3) [as added by AI05-0148-1]:
* The accessibility level of the type of a stand-alone object of an anonymous access-to-object type is the same as the accessibility level of the type of the access value most recently assigned to the object[, but]{; [Redundant: accessibility checks ensure that this} is never deeper than that of the declaration of the stand-alone object{]}.
Modify 3.10.1(13.3/3) [as added by AI05-0142-4]:
The accessibility level of an explicitly aliased (see 6.1) formal parameter in a function body is determined by the point of call [(which] {; it} is the same level that the return object ultimately will have[)].
Modify 5.4(6/3) [as modified by AI05-0188-1]:
The possible values of the selecting_expression shall be covered {(see 3.8.1)} as follows:
{AARM discussion: The meaning of "covered" here and in the following rules is that of the term "cover a value" that is defined in 3.8.1.}
Modify 6.2(11) [because of AI05-0142-4]:
For {other} parameters [of other types], it is unspecified whether the parameter is passed by copy or by reference.
Modify 6.2(12) [because of AI05-0142-4]:
If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified {and is not an explicitly aliased parameter}, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct).
!discussion
These wording changes seem to be an improvement in readability and understandability, but are not intended to change the meaning of the words.
!corrigendum 3.4(18/3)
Replace the paragraph:
The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1), other than those found in the designated profile of an access_definition, that is of the parent or progenitor type with a corresponding subtype of the derived type. For a given subtype of the parent or progenitor type, the corresponding subtype of the derived type is defined as follows:
by:
The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent or progenitor type, other than those subtypes found in the designated profile of an access_definition, with a corresponding subtype of the derived type. For a given subtype of the parent or progenitor type, the corresponding subtype of the derived type is defined as follows:
!corrigendum 3.10.1(8/3)
Replace the paragraph:
by:
!corrigendum 3.10.2(13.1/3)
Insert after the paragraph:
the new paragraphs:
!corrigendum 5.4(6)
Replace the paragraph:
The possible values of the expression shall be covered as follows:
by:
The possible values of the selecting_expression shall be covered (see 3.8.1) as follows:
!corrigendum 6.2(11)
Replace the paragraph:
For parameters of other types, it is unspecified whether the parameter is passed by copy or by reference.
by:
For other parameters, it is unspecified whether the parameter is passed by copy or by reference.
!corrigendum 6.2(12)
Replace the paragraph:
If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct).
by:
If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified and is not an explicitly aliased parameter, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct).
!ACATS test
No additional tests should be needed; the original AIs outline any needed tests.
!appendix

[Editor's note: These mails are organized by section of change, rather
than by the date.]

From: Tucker Taft
Sent: Tuesday, September 21, 2010  2:44 PM

The first sentence of paragraph 3.4(18/3) is a doozy:

   The profile of an inherited subprogram (including an inherited
   enumeration literal) is  obtained from the profile of the
   corresponding (user-defined) primitive subprogram of the
   parent or progenitor type, after systematic replacement of
   each subtype of its profile (see 6.1), other than those
   found in the designated profile of an access_definition,
   that is of the parent or progenitor type with a corresponding
   subtype of the derived type. ...


Perhaps it might be slightly easier if the "that is of the parent or progenitor
type" part were moved earlier and the word "subtypes" is added:

   The profile of an inherited subprogram (including an inherited
   enumeration literal) is  obtained from the profile of the
   corresponding (user-defined) primitive subprogram of the
   parent or progenitor type, after systematic replacement of
   each subtype of its profile (see 6.1) that is of the parent
   or progenitor type, other than those subtypes found in the designated
   profile of an access_definition, with a corresponding
   subtype of the derived type. ...

****************************************************************

From: Tucker Taft
Sent: Tuesday, September 21, 2010  3:29 PM

Paragraph 3.10.1(8/3) might be clearer with the following change:

  * as the subtype_mark in an access_definition {for an access-to-object type};

****************************************************************

From: Tucker Taft
Sent: Sunday, October 17, 2010  11:42 PM

These two paragraphs seem problematic.  I suggest the following minor edits:

13.2/3
   The accessibility level of the type of a stand-alone
   object of an anonymous access-to-object type is the same as the
   accessibility level of the type of the access value most recently
   assigned to the object[, but]{; [Redundant: accessibility checks
   ensure that this} is never deeper than that of the declaration
   of the stand-alone object{]}.

13.3/3
   The accessibility level of an explicitly aliased
   (see 6.1) formal parameter in a function body is determined by
   the point of call [(which] {; it} is the same level that the
   return object ultimately will have[)].

****************************************************************

From: Steve Baird
Sent: Friday, October 15, 2010   5:33 PM

In 5.4 (case statements), it seems that we never really define what choices are
covered by an "others" choice. I think it has been this way for years. Is this a
problem? Note that there is a legitimate question here about whether an others
clause covers values outside of the "covered" subtype (i.e., the subtype defined
in 7/3 - 9).

====

Noting the obvious, 5.5.1 (User-Defined Iterators) is not there yet.

====

The wording for exit statements and for goto statements is nonuniform.

For gotos, we get

    "The execution of a goto_statement transfers control to the target
     statement, completing the execution of any compound_statement that
     encloses the goto_statement but does not enclose the target.

For exit statements, there is no analogous "completing the execution of any
component_statement that ,,," wording. There should be.

====

In 6.1's "extensions to Ada 2005" section, we've got

    Parameters can now be explicitly aliased, allowing returning of
    values and forcing by-reference parameter passing.

"Allowing returning of values"? Well if we couldn't do that before, I suppose it
is a good thing that we can do that now. I think this was supposed to be
seomthing like "allowing function result parts to designate parameters"

====

6.2(12)
   If a( object is of a type for which the parameter passing mechanism is
   not specified, ...

With the introduction of aliased parameters, we don't want this test to be based
on the type of the parameter.  This should not apply, for example, to an aliased
parameter of type Integer.

Strictly speaking, the same applies to
   For parameters of other types, it is unspecified whether the parameter
   is passed by copy or by reference.

=====

In 6.3, the statement
   A subprogram_body is considered a declaration.
seems odd. Probably not enough of a problem here to justify changing
well-established wording. But it is odd.

====
In 6.4's Name Resolution Rules section, we see
   This rule is an overloading rule (see 8.6).

Any rule that occurs in a Name Resolution Rules section is an overloading rule.
Is this a helpful (albeit redundant) clarification, or a harmful suggestion that
perhaps this statement is actually necessary for some reason.

How about leaving the statement in, but flagging it as redundant?

====

The 6.4.1 rules for rejecting calls with evaluation order dependencies seem like
a lot of complication for very little benefit, but we've already had that
discussion.

====

6.5
Can an extended return statement declare a return object of an abstract type?

   function F return T'Class is
   begin
       return X : Abstract_Extension_Of_T := A_E_O_T (Y);

If that's supposed to be illegal, what rule enforces that?

====

6.7:
We want to disallow pre- and post-conditions on null procedures, right?
Otherwise, we have problems with the "just pick one, it doesn't matter which"
model that is used when we inherit multiple null procedures from multiple
progenitors. Is this properly enforced?

====

7.3(1.a):
   A private (untagged) type can be thought of as a record type with the
   type of its single (hidden) component being the full view.

Add "undiscriminated", as in
  A private (untagged and undiscriminated) private type can ...
?

Is this too pedantic?

Similarly, 1.b doesn't mention classwide streaming operations:

   A private tagged type can be thought of as a private extension of an
   anonymous parent with no components. The only dispatching operation of
   the parent is equality (although the Size attribute, and, if
   nonlimited, assignment are allowed, and those will presumably be
   implemented in terms of dispatching).

Should it?

====

7.3(7) refers to "derivatives", as in
   "no derivatives of the partial view are allowed"

This term is never really defined (see 3.4, which simply introduces the term by
using it). Do we care?

Would a glossary entry be appropriate?

====

7.4(6/3).

interactions between deferred constants and predicates need to be worked out.

====

7.6(17.1/3) says:
    When a function call or aggregate is used to initialize an object, .
    ...  Under certain circumstances, the anonymous object is required to
    be built in place,

What about when a parentheisized expression, qualified expression, or
conditional expression is used to initialize an object?

====

If the entire "Implementation Requirements" section of 7.6 has been deleted,
then shuld the two-word section heading (i.e., "Implementation Requirements")
also be deleted?

=====

Chapter 8 looks fine. There would have been more to chew on here if we were
dealing with integrated packages.

****************************************************************

From: Bob Duff
Sent: Friday, October 15, 2010   6:09 PM

> In 5.4 (case statements), it seems that we never really define what
> choices are covered by an "others" choice. I think it has been this
> way for years.

I think we should focus on "new bugs".  Two kinds:

    The new feature wording has bugs.

    Regressions: The new feature wording causes bugs in old features.

I think we should ignore old bugs in old features.

In this particular case, I think it's covered by (pun!) 3.8.1 (variant parts):

12.a      Ramification: For case_statements, this includes values outside the
          range of the static subtype (if any) to be covered by the choices.
          It even includes values outside the base range of the case
          expression's type, since values of numeric types (and undefined
          values of any scalar type?) can be outside their base range.

But even if that weren't the case, I don't think the RM review needs to go
looking for old bugs in old features, unless some compiler writer is honestly
confused about what to do, or some programmer is honestly confused about what to
expect from compilers.

> interactions between deferred constants and predicates need to be
> worked out.

Right.  Please pester me about that until I get it done.  ;-)

- Bob

P.S. Is anybody going to read the new RM cover to cover?  I got "volunteered"
for that last time 'round, and it was a HUGE job. But I did find some
interesting problems.  That's how "prefix views" got invented, at the last
minute, if I recall correctly.

I suppose this will be my job yet again, although I fear the RM has gone well
beyond human comprehension this time.  Sigh.

****************************************************************

From: Randy Brukardt
Sent: Friday, October 15, 2010   6:49 PM

> > In 5.4 (case statements), it seems that we never really define what
> > choices are covered by an "others" choice. I think it has been this
> > way for years.
>
> I think we should focus on "new bugs".  Two kinds:
>
>     The new feature wording has bugs.
>
>     Regressions: The new feature wording causes bugs in old features.
>
> I think we should ignore old bugs in old features.

I agree for the most part.

I am suggesting changing the wording of case statements slightly in order to
make the wording for case expressions easier (the current case expression
wording makes it really hard to determine which of the rules in 5.4 apply to
case expressions - and not all of them do apply). The suggested change is to
give "expression" a prefix so we don't have the say the clunky "expression of
the case statement", especially as there are lots of expressions that make up
the case statement. So I suppose we could fix any missing wording at the same
time. (But you point out that the wording isn't missing, it's just in 3.8.1 will
a lot of the other case statement rules -- the place no one thinks to look).

...
> P.S. Is anybody going to read the new RM cover to cover?  I got
> "volunteered" for that last time 'round, and it was a HUGE job.
> But I did find some interesting problems.  That's how "prefix views"
> got invented, at the last minute, if I recall correctly.
>
> I suppose this will be my job yet again, although I fear the RM has
> gone well beyond human comprehension this time.  Sigh.

I wasn't planning to require anyone to read the entire thing; the point of this
review was to get 90% of that done now, with the labor split up. We'll do
another similar review at the last minute. But since you have volunteered to
read the whole thing... :-)

****************************************************************

From: Randy Brukardt
Sent: Monday, February  7, 2011  10:07 PM

[Note that there are questions and an assignment for an AI below.]

...
> In 5.4 (case statements), it seems that we never really define what
> choices are covered by an "others" choice. I think it has been this
> way for years. Is this a problem? Note that there is a legitimate
> question here about whether an others clause covers values outside of
> the "covered" subtype (i.e., the subtype defined in 7/3 - 9).

Bob explained that this is defined in 3.8.1. The problem here is that no one
ever thinks to look in 3.8.1 for this information (I know *I* don't!). In
particular, 5.4(6-10, 12) all depend on the definition of "covers a value" in
3.8.1. Indeed, I didn't realize until just now that 5.4(6-10) actually depends
on a formal term; I always thought that they were informally defined.

So I think the addition of a cross-reference to 3.8.1 in 5.4(6) would be
helpful, even though it is not technically a forward reference. (This term is
only used here, so it is not one that is immediately familiar to readers.) The
AARM Note is needed only because looking for "covered" won't get you anywhere,
and it took me a while to realize that "value" does indeed appear in this
sentence (the two important words are a long ways apart).

That is:

The possible values of the expression shall be covered {(see 3.8.1)} as
follows:

AARM discussion: The meaning of "covered" here and in the following rules is
that of the term "cover a value" that is defined in 3.8.1.

...
> ====
>
> The wording for exit statements and for goto statements is nonuniform.
>
> For gotos, we get
>
>     "The execution of a goto_statement transfers control to the target
>      statement, completing the execution of any compound_statement
> that
>      encloses the goto_statement but does not enclose the target.
>
> For exit statements, there is no analogous "completing the execution
> of any component_statement that ,,," wording. There should be.

I don't see this. It seems to me that the only reason that gotos mention
compound_statements at all is to get a form of the word "complete" into the
sentence. The rules in 7.6.1 for completion and transfer of control surely apply
in both of these case. Also note that there is no such wording for return
statements, either; they also depend on "transfer of control" to do the right
thing.

In any case, Bob's "nothing has changed here, we're not fixing old problems"
surely applies here.

...
> ====
>
> 6.2(12)
>    If a( object is of a type for which the parameter passing mechanism
> is
>    not specified, ...
>
> With the introduction of aliased parameters, we don't want this test
> to be based on the type of the parameter.  This should not apply, for
> example, to an aliased parameter of type Integer.
>
> Strictly speaking, the same applies to
>    For parameters of other types, it is unspecified whether the
> parameter
>    is passed by copy or by reference.

This seems to be a real problem. The first paragraph (the second one you
mention) is easy. I suggest:

6.2(11):

For {other} parameters [of other types], it is unspecified whether the parameter
is passed by copy or by reference.

[Is this specific enough? The rules that specify parameters that have specified
parameter passing are widely separated in 6.2(3/3) and 6.2(10/3).]

The second one is tougher. Not all of the objects talked about there are
parameters; for non-parameters the type is surely relevant. So the easiest
solution is to use the same one we used in 6.2(3) and 6.2(10): exclude aliased
parameters explicitly:

6.2(12):

If one name denotes a part of a formal parameter, and a second name denotes a
part of a distinct formal parameter or an object that is not part of a formal
parameter, then the two names are considered distinct access paths. If an object
is of a type for which the parameter passing mechanism is not specified {and is
not an explicitly aliased parameter}, then it is a bounded error to assign to
the object via one access path, and then read the value of the object via a
distinct access path, unless the first access path denotes a part of a formal
parameter that no longer exists at the point of the second access (due to
leaving the corresponding callable construct).

> =====
>
> In 6.3, the statement
>    A subprogram_body is considered a declaration.
> seems odd. Probably not enough of a problem here to justify changing
> well-established wording.
> But it is odd.

It's bizarre, to the point we already had an AI about it (AI-222). We decided
not to change anything.

> ====
> In 6.4's Name Resolution Rules section, we see
>    This rule is an overloading rule (see 8.6).
>
> Any rule that occurs in a Name Resolution Rules section is an
> overloading rule. Is this a helpful (albeit redundant) clarification,
> or a harmful suggestion that perhaps this statement is actually
> necessary for some reason.
>
> How about leaving the statement in, but flagging it as redundant?

Makes sense to me. I think it is leftover Ada 83 junk, more confusing than
helpful. In any case, this is just an AARM change so I don't have to mention it
beyond this reply.

...
> ====
>
> 6.5
> Can an extended return statement declare a return object of an
> abstract type?
>
>    function F return T'Class is
>    begin
>        return X : Abstract_Extension_Of_T := A_E_O_T (Y);
>
> If that's supposed to be illegal, what rule enforces that?

3.9.3(8/3) says:

The type denoted by a return_subtype_indication (see 6.5) shall not be abstract.

Looks like it's covered to me - by AI05-0203-1. Looks like Adam beat you to this
question by a year.

> ====
>
> 6.7:
> We want to disallow pre- and post-conditions on null procedures,
> right? Otherwise, we have problems with the "just pick one, it doesn't
> matter which" model that is used when we inherit multiple null
> procedures from multiple progenitors.
> Is this properly enforced?

AI05-0230-1 covered this.

> ====
>
> 7.3(1.a):
>    A private (untagged) type can be thought of as a record type with
> the
>    type of its single (hidden) component being the full view.
>
> Add "undiscriminated", as in
>   A private (untagged and undiscriminated) private type can ...
> ?
>
> Is this too pedantic?

Yes, since defaulted discriminants work with this definition. And you *can think
of* if it even when discriminated (it's just not quite legal, but the model
still works).

The only change I would make to this note is to get rid of it, since it
conflicts with the "view" model that we now use heavily. And I can't imagine
what help this "component model" is supposed to provide -- it still requiring
thinking about hidden component(s) -- it doesn't matter if there are one or more
such components. So far as I can tell it's meaningless; why confuse readers with
it.

> Similarly, 1.b doesn't mention classwide streaming operations:
>
>    A private tagged type can be thought of as a private extension of
> an
>    anonymous parent with no components. The only dispatching operation
> of
>    the parent is equality (although the Size attribute, and, if
>    nonlimited, assignment are allowed, and those will presumably be
>    implemented in terms of dispatching).
>
> Should it?

Again, I'm not sure what the point is. It seems more confusing than helpful,
especially once the "pedantic" thoughts are applied. Perhaps Bob or Tuck can
enlighten us.

====
>
> 7.3(7) refers to "derivatives", as in
>    "no derivatives of the partial view are allowed"
>
> This term is never really defined (see 3.4, which simply introduces
> the term by using it). Do we care?
>
> Would a glossary entry be appropriate?

I'd say insuffienctly broken. Maybe an index entry, but even that is a stretch
(it's pretty obvious what is being talked about).

I'd probably just fix it if anybody cares enough ("derivatives of the partial
view" => "derived types whose parent type is the partial view", same for the
full view). But I won't do that unless someone indicates that they care.

> ====
>
> 7.4(6/3).
>
> interactions between deferred constants and predicates need to be
> worked out.

What are you thinking about? I'm not aware of any "interactions".

> ====
>
> 7.6(17.1/3) says:
>     When a function call or aggregate is used to initialize an object,
> .
>     ...  Under certain circumstances, the anonymous object is required
> to
>     be built in place,
>
> What about when a parentheisized expression, qualified expression, or
> conditional expression is used to initialize an object?

I think we need a general fix for this, there are far too many rules where we
have to add text about one or all of these things. I assign Steve Baird to
create an AI to address this problem once and for all.

> ====
>
> If the entire "Implementation Requirements" section of 7.6 has been
> deleted, then shuld the two-word section heading (i.e.,
> "Implementation Requirements") also be deleted?

It says around because of the "deleted paragraph" notations; it would disappear
if/when we remove those. In this case, since this was originally an inserted
paragraph, we don't need the "deleted paragraph" notation, so I've turned that
off.

****************************************************************

Questions? Ask the ACAA Technical Agent