CVS difference for ai12s/ai12-0205-1.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0205-1.txt

--- ai12s/ai12-0205-1.txt	2020/01/11 04:32:53	1.7
+++ ai12s/ai12-0205-1.txt	2020/05/02 03:43:13	1.8
@@ -1,9 +1,11 @@
-!standard 12.3(7/3)                                  20-01-10  AI12-0205-1/04
+!standard 12.3(7/3)                                  20-04-30  AI12-0205-1/05
 !standard 12.3(10)
 !standard 12.5(2.1/3)
 !standard 12.5(2.2/3)
 !standard 12.5(7/2)
 !class amendment 16-10-06
+!status Amendment 1-2012 20-04-30
+!status ARG Approved 10-1-3  20-04-30
 !status work item 19-10-06
 !status Hold 18-12-10 (11-0-0)
 !status work item 16-10-06
@@ -31,9 +33,6 @@
 
 !proposal
 
-[NOTE: Now that !wording is added, maybe this section should be changed
-to read simply "(See !summary.)"?]
-
 12.5(2.1-2.2) is modified to read
 
   formal_complete_type_declaration ::=
@@ -64,9 +63,9 @@
 synonym for generic actual parameter and also for the view denoted by one,
 or the value of one.
 
-AARM Discussion: Any matching or other Legality Rules that apply to a 
-an generic actual are applied to any default_expression, \default_\subtype_mark,
-or default_name that are used for an actual.
+AARM Ramification: Any matching or other Legality Rules that apply to a 
+a generic actual are applied to any default_expression, \default_\subtype_mark,
+or default_name that are used as an actual.
 
 [Editor's note: Steve was unsure if the Legality Rules applied to defaults. I 
 think it is obvious (a default *is* an actual, and the Legality Rules aren't
@@ -141,13 +140,13 @@
 
 This rule does not allow any formal types that depend on other formal types
 of the generic to have a default_subtype_mark unless that default is another
-formal type  of the generic.
+formal type of the generic.
 
 We attempted to find a model that would allow types that depend on other
 formal types to have defaults.
 
 Simply allowing any subtype of the right category is tempting. Any instance
-will be detect the error, as every rule that applies to an actual type applies
+will detect the error, as every rule that applies to an actual type applies
 to an actual type that is specified by a default (the definition is that the
 default IS the actual type). However, this means that defaults can cause
 "hidden contracts" by adding requirements to other formals. For instance:
@@ -203,7 +202,7 @@
       with function Is_Positive (A : in Element_Type) return Boolean;
     procedure Gen4 is
 
-The proposed rule would fail here as an test instance of 
+The proposed rule would fail here as a test instance of 
 Gen4 (Long_Float, Is_Positive); would be illegal. One could imagine fixing that
 by extending the rules to default_names for formal subprograms (this would
 be compatible, as a default_name for a formal subprogram like Is_Positive
@@ -220,12 +219,12 @@
 The second point simply follows from this being a non-critical feature for
 Ada and therefore a lot of implementation complexity isn't justifiable.
 
-The simpler rule proposed here works for the use cases that have suggested
-for defaults. It also could be compatibly extended in the future to use a
-a more complex rule, preferably one that applied to all kinds of defaults
-in a generic instance. (It seems inconsistent to have special rules to allow
-type defaults to depend on other formals, but not have such rules for other
-kinds of generic formal defaults.)
+The simpler rule proposed here works for the use cases that have been 
+suggested for subtype defaults. It also could be compatibly extended in the 
+future to use a more complex rule, preferably one that applied to all kinds 
+of defaults in a generic instance. (It seems inconsistent to have special 
+rules to allow type defaults to depend on other formals, but not have such
+rules for other kinds of generic formal defaults.)
 
 !example
 
@@ -271,7 +270,7 @@
 All operations would maintain L.N, e.g. Append would add 1. When this was
 discussed on comp.lang.ada, some people argued that if one has lists of oranges
 and lists of apples, these should be counted using different types to avoid
-inadvertantly adding apple counts and orange counts. Hence the interface
+inadvertently adding apple counts and orange counts. Hence the interface
 should be modified:
 
 generic
@@ -312,6 +311,65 @@
 
 end Lists;
 
+!corrigendum 12.3(7/3)
+
+@drepl
+The @i<generic actual parameter> is either the @fa<explicit_generic_actual_parameter>
+given in a @fa<generic_association> for each formal, or the
+corresponding @fa<default_expression> or @fa<default_name> if no
+@fa<generic_association> is given for the formal. When the meaning
+is clear from context, the term "generic actual," or simply "actual," is used
+as a synonym for "generic actual parameter" and also for the view denoted by one,
+or the value of one. 
+@dby
+The @i<generic actual parameter> is either the @fa<explicit_generic_actual_parameter>
+given in a @fa<generic_association> for each formal, or the
+corresponding @fa<default_expression>, @i<default_>@fa<subtype_mark>, 
+or @fa<default_name> if no @fa<generic_association> is given for the formal. 
+When the meaning is clear from context, the term "generic actual", or simply 
+"actual", is used as a synonym for "generic actual parameter" and also for the 
+view denoted by one, or the value of one. 
+
+!corrigendum 12.3(10)
+
+@drepl
+A @fa<generic_instantiation> shall contain at most one @fa<generic_association>
+for each formal. Each formal without an association shall have a 
+@fa<default_expression> or @fa<subprogram_default>.
+@dby
+A @fa<generic_instantiation> shall contain at most one @fa<generic_association>
+for each formal. Each formal without an association shall have a 
+@fa<default_expression>, @i<default_>@fa<subtype_mark>, or
+@fa<subprogram_default>.
+
+!corrigendum 12.5(2.1/3)
+
+@drepl
+@xindent<@fa<formal_complete_type_declaration>@fa<@ ::=@ >@hr
+@ @ @ @ @b<type> @fa<defining_identifier>[@fa<discriminant_part>] @b<is> @fa<formal_type_definition>@hr
+@ @ @ @ @ @ [@fa<aspect_specification>];>
+@dby
+@xindent<@fa<formal_complete_type_declaration>@fa<@ ::=@ >@hr
+@ @ @ @ @b<type> @fa<defining_identifier>[@fa<discriminant_part>] @b<is> @fa<formal_type_definition>@hr
+@ @ @ @ @ @ @ @ [@b<or use> @i<default_>@fa<subtype_mark>] [@fa<aspect_specification>];>
+
+!corrigendum 12.5(2.2/3)
+
+@drepl
+@xindent<@fa<formal_incomplete_type_declaration>@fa<@ ::=@ >@hr
+@ @ @ @ @b<type> @fa<defining_identifier>[@fa<discriminant_part>] [@b<is tagged>];>
+@dby
+@xindent<@fa<formal_incomplete_type_declaration>@fa<@ ::=@ >@hr
+@ @ @ @ @b<type> @fa<defining_identifier>[@fa<discriminant_part>] [@b<is tagged>]@hr
+@ @ @ @ @ @ @ @ [@b<or use> @i<default_>@fa<subtype_mark>];>
+
+!corrigendum 12.5(7/2)
+
+@dinsa
+The actual type shall be in the category determined for the formal.
+@dinst
+The @i<default_>@fa<subtype_mark>, if any, shall denote a subtype which is 
+allowed as an actual subtype for the formal type.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent