!standard 7.3.4(2/5)                                  18-08-31  AI12-0285-1/03
!standard 7.3.4(3/5)
!standard 7.3.4(4/5)
!standard 7.3.4(6/5)
!standard 7.3.4(7/5)
!standard 7.3.4(9/5)
!standard 7.3.4(10/5)
!standard 7.3.4(14/5)
!standard 13.1.1(4/5)
!class Amendment 18-06-12
!status Amendment 1-2012 18-07-06
!status WG9 Approved 16-10-22
!status ARG Approved 9-0-0  18-06-23
!status work item 18-06-12
!status received 18-06-12
!priority Low
!difficulty Easy
!subject Syntax for Stable_Properties aspects
!summary

Positional array aggregate syntax is used for Stable_Properties aspects.

!problem

The syntax proposed in AI12-0187-1 is essentially a
comma-delimited list. However, aspect specifications themselves are
comma-delimited lists. This makes the syntax ambiguous when a
Boolean values aspect is used:

    type Ugh is ...
        with Stable_Properties => Foo, Bar, Nonblocking, Pack;

Unfortunately, here Nonblocking and Pack are intended to be the names
of aspects, but they look like they're part of the Stable_Properties
aspect.

!proposal

Use positional array aggregate syntax to define Stable_Properties aspects.

!wording

Delete 7.3.4(2/5) and 7.3.4(3/5).

[Editor's note: Once these changes are made, the paragraph numbers of the
entire subclause will change.]

Add after 7.3.4(4/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/ written in the syntax of a 
   positional_array_aggregate.

   To Be Honest: A single name would technically be a parenthesized expression
   rather than an aggregate; we mean to include that here. We say "syntax of
   a positional_array_aggregate" to hopefully clarify that the specification
   is in no other way an actual aggregate.

Modify 7.3.4(6/5):

Stable_Properties
   This aspect shall be specified by a {type property aspect 
   definition}[type_property_aspect_definition]; each name
   shall statically denote a single property function of the type. This aspect
   defines the *stable property functions* of the associated type.

Modify 7.3.4(7/5):

Stable_Properties'Class
   This aspect shall be specified by a {type property aspect 
   definition}[type_property_aspect_definition]; each name
   shall statically denote a single property function of the type. This aspect
   defines the class-wide stable property functions of the associated type.
   Redundant[Unlike most class-wide aspects, Stable_Properties'Class is not 
   inherited by descendant types and subprograms, but the enhanced class-wide 
   postconditions are inherited in the normal manner.]

Modify 7.3.4(9/5):

Stable_Properties
   This aspect shall be specified by a {subprogram property aspect 
   definition}[subprogram_property_aspect_definition]; each name shall
   statically denote a single property function of a type for which the 
   associated subprogram is primitive.

Modify 7.3.4(10/5):

Stable_Properties'Class
   This aspect shall be specified by a {subprogram property aspect 
   definition}[subprogram_property_aspect_definition]; each name shall
   statically denote a single property function of a tagged type for which the
   associated  subprogram is primitive. Redundant[Unlike most class-wide 
   aspects, Stable_Properties'Class is not inherited by descendant subprograms,
   but the enhanced class-wide postconditions are inherited in the normal manner.]

Modify 7.3.4(14/5):

In a {subprogram property aspect
definition}[subprogram_property_aspect_definition] for a subprogram *S*:

Replace 13.1.1(4/5) with: (this includes the change of AI12-0212-1 - 
note that the syntax change is missing from that AI)

aspect_definition ::= 
   name | expression | identifier | aggregate

!discussion

AI12-0212-1 generalized aspect specifications to allow the syntax of an
aggregate to be one of the choices. We take advantage of this change
to define the syntax of a Stable_Properties aspect to be that of a
positional array aggregate.

This is intended to be just a syntax change. I tried rewriting this without
defining "type property aspect definition" and "subprogram property aspect 
definition", but that turned long sentences longer and was very repetitive.
So, for most of the text, this change is just removing the underscores
as these are no longer syntax terms.

!example

The example in the !problem should now be written:

    type Ugh is ...
        with Stable_Properties => (Foo, Bar), Nonblocking, Pack;

!corrigendum 7.3.4(0)

@dinsc
Just enough to force a conflict. The actual text is found in the conflict
file.

!corrigendum 13.1.1(4/3)

@drepl
@xcode<@fa<aspect_definition ::= name | expression | identifier>>
@dby
@xcode<@fa<aspect_definition>@fa< ::=>
   @fa<name>@fa< | >@fa<expression>@fa< | >@fa<identifier>@fa< | >@fa<aggregate>>

!ASIS

None needed.

!ACATS test

Any tests needed will be associated with the original AI (AI12-0187-1).

!appendix

From: Randy Brukardt
Sent: Tuesday, June 12, 2018  9:28 PM

When I was working on the container contract AI, I discovered that I had given
the Stable_Properties aspects a syntax that is ambiguous. Since Tucker has 
since added rules (but not syntax :-) to allow an aggregate (really, the 
syntax of an aggregate) to be given as the value of an aspect, it makes the 
most sense to replace the dedicated syntax of AI12-0187-1 with that of a 
positional array aggregate. So I've attached version /01 of an AI to do that.

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