!standard 3.10(9/5)                                    19-04-02  AI12-0324-1/02
!standard 3.10.2(19.2/5)
!standard 4.3.4(0)
!standard 6.4.1(6.17/5)
!standard 7.3.3(0)
!standard 7.3.4(0)
!standard 8.6(17.1/4)
!standard D.4(1/3)
!class binding interpretation 19-03-19
!status Amendment 1-2012 19-03-19
!status work item 19-03-19
!status received 19-03-06
!priority Low
!difficulty Easy
!qualifier Clarification
!subject More changes from the RM review
!summary

Various wording changes are made to clarify the Standard.

!question

(1) The change in 3.10(9/5) reads:

     A qualified_expression is an aliased view when the operand denotes
     an aliased view.

It's odd that we say something "is" a view when something else "denotes"
a view. Should "is an aliased" be replaced with "denotes an aliased"? (Yes.)

(2) The start of 3.10.2(19.2/5) is hard to read:

     Inside a return statement that applies to a function or generic
     function F, or the return expression of an expression function F, ...

Should we make this easier to read? (Yes.)

(3) There are three queuing policies defined in D.4 (D.4(7/5) says that
explicitly), but D.4(1/3) says there are only two. Should this be fixed? (Yes.)

(4) The wording for 7.3.3(6/5) seems be a charter member of the Department
of Redundancy Department. It says:

... then a default initial condition check is performed after successful 
default initialization of an object of type T by default (see 3.3.1). ...

"Default initialization ... by default"?? Should this be changed? (Yes.)

(5) Some of the text of 7.3.4 requires improvement. Should we make these
improvements? (Yes.)

(6) 8.6(17.1/4) talks about the "execution of the usage name", but names
are evaluated, not executed. Should this be fixed? (Yes.)

(7) 6.4.1(6.17/5) is wordier than necessary. Should it be simplified? (Yes.)

(8) 4.3.4(1/5) reads awkwardly, as it has two gerund forms close together 
("resulting from starting with"). Should this be improved? (Yes.)

(9) The first sentence of 4.3.4(14/5) is awkward. The the phrase "and using
that value..." sounds ungrammatical in the context of the earlier part of 
the sentence. Should this be revised? (Yes.)

(10) The example of 4.3.4(27/5) will always raise Constraint_Error, which
probably isn't what is intended. Should this be changed? (Yes.)

!recommendation

(1) Use "denotes" rather than "is".

(2) Add a second use of "inside".

(3) Change "two" to "three".

(4) Delete the extra "by default".

(5) See the !wording for the exact changes.

(6) Replace "with" with "of" and "execution" with "evaluation".

(7) Replace "that denotes" with "denoting" and "and" with "that".

(8) Simplify the entire paragraph.

(9) Replace "and using that value" with ", then that value is used"

(10) Replace the example.

!wording

(1) Modify 3.10(9/5):

... A qualified_expression {denotes}[is] an 
aliased view when the operand denotes an aliased view. 

(2) Modify 3.10.2(19.2/5):

     Inside a return statement that applies to a function or generic
     function F, or {inside} the return expression of an expression 
     function F, ...

(3) Modify D.4(1/3):

    This subclause clause specifies a mechanism for a user to choose an entry 
    queuing policy. It also defines {three}[two] such policies. Other policies 
    are implementation defined.

(4) Modify 7.3.3(6/5):

    If one or more default initial condition expressions apply to a type T, 
    then a default initial condition check is performed after successful 
    [default] initialization of an object of type T by default (see 3.3.1). 
    In the case of a controlled type, the check is performed after the call 
    to the type's Initialize procedure (see 7.6).

(5) Modify 7.3.4(1/5):

    [It is usual that some of the] {Certain} characteristics of 
    [a data] {an object of a given} type are unchanged by most of 
    the primitive operations [on]{of} the type. Such 
    characteristics are called /stable properties/ of the type. 

    Modify 7.3.4(3/5):

    A /type property aspect definition/ is a list of names 
    written in the syntax of a positional_array_aggregate. A 
    /subprogram property aspect definition/ is a list of names 
    preceded by an optional *not*{, also} written in the syntax 
    of a positional_array_aggregate.

    Modify 7.3.4(16/5):

    For a primitive subprogram S of a type T, the stable property 
    functions [for] {of} S for type T are:

    Modify 7.3.4(22/5):

    ... [where F is]{with one such equality included for} each 
    stable property function {F} of S for type T that does not occur 
    in the explicit specific postcondition expression of S ...

    Modify 7.3.4(23/5):

    ... [where F is]{with one such equality included for} each 
    class-wide stable property function {F} of S for type T that does 
    not occur in any class-wide postcondition expression that 
    applies to S ...

(6) Modify 8.6(17.1/4):

    ... If the type or subtype is by-reference, the associated object
    [with]{of} the value is the object associated (see 6.2) with the 
    [execution]{evaluation} of the usage name.

(7) Modify 6.4.1(6.17/5):

    ...[that denotes] {denoting} an object of an elementary type 
    {that}[and] is passed ...

(8) Modify 4.3.4(1/5):

    A (record or array) delta aggregate yields a composite value {that starts}
    [resulting from starting] with a copy of another value of the same type 
    and then {assigns}[subsequently assigning] to some (but typically not all)
    components of the copy. 

(9) Modify 4.3.4(14/5):

    The evaluation of a delta_aggregate begins with the evaluation of the 
    base_expression of the delta_aggregate{; then}[ and using] that value
    {is used }to create and initialize the anonymous object of the aggregate. 
    The bounds of the anonymous object of an array_delta_aggregate and the 
    discriminants and tag (if any) of the anonymous object of a 
    record_delta_aggregate are those of the base_expression.

(10) Replace 4.3.4(27/5):

     A1 : Vector := ((0 => 0.0, 1 => 1.0, 2 => 2.0) with delta 
                            Integer(Random * 2.0) => 14.2);
 
!discussion

For (1), the wording surrounding the new sentence with uses "is defined to be 
aliased" or "denotes an aliased view". We ought to use one of these phrasings.

For (8), the text seems to have a number of extra words. Changing the verb
tense seems to help, too.

!corrigendum 3.10(9/3)

@drepl
A view of an object is defined to be @i<aliased> if it is defined by an
@fa<object_declaration>, @fa<component_definition>, @fa<parameter_specification>, or
@fa<extended_return_object_declaration>
with the reserved word @b<aliased>, or by a renaming of an aliased view. In addition,
the dereference of an access-to-object value denotes an aliased view, as does a view
conversion (see 4.6) of an aliased view. The current instance of an immutably
limited type (see 7.5) is defined to be aliased.
Finally, a formal parameter or generic formal object of a tagged type is
defined to be aliased. Aliased views are the ones that can be designated by
an access value.
@dby
A view of an object is defined to be @i<aliased> if it is defined by an
@fa<object_declaration>, @fa<component_definition>, @fa<parameter_specification>, or
@fa<extended_return_object_declaration>
with the reserved word @b<aliased>, or by a renaming of an aliased view. In addition,
the dereference of an access-to-object value denotes an aliased view, as does a view
conversion (see 4.6) of an aliased view. A @fa<qualified_expression> denotes an 
aliased view when the operand denotes an aliased view. The current instance 
of an immutably limited type (see 7.5) is defined to be aliased.
Finally, a formal parameter or generic formal object of a tagged type is
defined to be aliased. Aliased views are the ones that can be designated by
an access value.

!corrigendum 3.10.2(19.2/4)

@drepl
@xbullet<Inside a return statement that applies to a function or generic
function @i<F>, or the return expression of an expression function @i<F>, when
determining whether the accessibility level of an explicitly
aliased parameter of @i<F> is statically deeper than the level of the
return object of @i<F>, the level of the return object is considered to
be the same as that of the level of the explicitly aliased
parameter; for statically comparing with the level of other
entities, an explicitly aliased parameter of @i<F> is considered to have
the accessibility level of the body of @i<F>.>
@dby
@xbullet<Inside a return statement that applies to a function or generic
function @i<F>, or inside the return expression of an expression function 
@i<F>, when determining whether the accessibility level of an explicitly
aliased parameter of @i<F> is statically deeper than the level of the
return object of @i<F>, the level of the return object is considered to
be the same as that of the level of the explicitly aliased
parameter; for statically comparing with the level of other
entities, an explicitly aliased parameter of @i<F> is considered to have
the accessibility level of a parameter of @i<F> that is not explicitly 
aliased.>

!corrigendum 4.3.4(0)

@dinsc
Just enough to cause a conflict; the real changes are in the conflict 
file.

!corrigendum 6.4.1(6.17/3)

@drepl
@xbullet<For each @fa<name> @i<N> that is passed as a parameter of mode
@b<in out> or @b<out> to the call @i<C>, there is no other @fa<name> among the
other parameters of mode @b<in out> or @b<out> to @i<C> that is known to
denote the same object.>
@dby
@xbullet<For each @fa<name> @i<N> denoting an object of an elementary type
that is passed as a parameter of mode @b<in out> or @b<out> to the call @i<C>,
there is no other @fa<name> among the other parameters of mode @b<in out> or
@b<out> to @i<C> that is known to denote the same object.>

!corrigendum 7.3.3(0)

@dinsc
Just enough to cause a conflict; the real changes are in the conflict 
file.

!corrigendum 7.3.4(0)

@dinsc
Just enough to cause a conflict; the real changes are in the conflict 
file.

!corrigendum 8.6(17.1/4)

@drepl
@xindent<Within an @fa<aspect_specification> for a type or subtype, the
current instance represents a value of the type; it is not an object. The
nominal subtype of this value is given by the subtype itself (the
first subtype in the case of a @fa<type_declaration>), prior to applying
any predicate specified directly on the type or subtype. If the type or
subtype is by-reference, the associated object with the value is the
object associated (see 6.2) with the execution of the usage name.>
@dby
@xindent<Within an @fa<aspect_specification> for a type or subtype, the
current instance represents a value of the type; it is not an object. The
nominal subtype of this value is given by the subtype itself (the
first subtype in the case of a @fa<type_declaration>), prior to applying
any predicate specified directly on the type or subtype. If the type or
subtype is by-reference, the associated object of the value is the
object associated (see 6.2) with the evaluation of the usage name.>

!corrigendum D.4(1/3)

@drepl
This subclause specifies a mechanism for a user to choose an entry @i<queuing
policy>. It also defines two such policies. Other policies are implementation
defined.
@dby
This subclause specifies a mechanism for a user to choose an entry @i<queuing
policy>. It also defines three such policies. Other policies are implementation
defined.


!ASIS

No ASIS effect.

!ACATS test

No ACATS tests should be needed, all of these are mainly wording improvements.

!appendix

From: Randy Brukardt
Written: Tuesday, March 19, 2019  9:59 PM

Steve's review includes:

>3.10 -
>   The new wording (which presumably was discussed when the AI12-0228 was
>   approved) is
>      A qualified_expression is an aliased view when the operand denotes
>      an aliased view.
>   Should "is an aliased" be replaced with "denotes an aliased"?

AIs tend to discuss wording in a vacuum, while this review is to read the 
wording in place. 

Anyway, the wording around this either uses "is defined to be aliased" or 
"denotes an aliased view", so this appears wrong to just use "is". One for
the cleanup AI.

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