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

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

--- ai12s/ai12-0205-1.txt	2019/11/08 04:28:20	1.5
+++ ai12s/ai12-0205-1.txt	2020/01/10 01:22:00	1.6
@@ -1,4 +1,4 @@
-!standard 12.3(7/3)                                  18-12-06  AI12-0205-1/02
+!standard 12.3(7/3)                                  20-01-06  AI12-0205-1/03
 !standard 12.3(10)
 !standard 12.5(2.1/3)
 !standard 12.5(2.2/3)
@@ -85,6 +85,66 @@
 The \default_\subtype_mark, if any, shall denote a subtype in the category
 determined for the formal type.
+For a formal type with a \default_\subtype_mark, if the declaration depends 
+on some other formal type \F\ of the same generic_formal_part, the 
+declaration of \F\ shall also have a \default_\subtype_mark. For the purposes
+of this check, a type declared in a formal package of a generic_formal_part
+is considered a formal type of the generic_formal_part that does not have
+a \default_\subtype_mark.
+AARM Reason: We require this so that the defaults are useful. If this wasn't 
+true, the default could only be used if the type without a default is 
+specified as a specific actual value. For example:
+    generic
+      type Elem is digits <>;
+      type Arr is array (Positive range <>) of Elem or use Float_Array; -- Illegal.
+If this was allowed, the actual for Elem would have to be Float in order to 
+use the default. This sort of implied contract is confusing and not very 
+useful. If Elem also has a default, then both parameters can be omitted from 
+instances. [Editor's note: Bob asked for this note to be added with this wording.]
+The last sentence ensures that formal types that depend on a formal package
+do not allow defaults, as the formal package would have to export a specific
+type for the default to work, and this would be another form of implied 
+contract. Whether the exported type itself has a default is irrelevant, as
+there is no way to ensure that the actual instance uses it. [Editor's note: 
+If we allow formal package defaults, then we should revisit this.]
+End AARM Reason.
+AARM Discussion: A formal type can depend on another in many ways. Some examples
+  * the designated type of a formal access type;
+  * the component type of a formal array type;
+  * the ancestor type of a formal derived type.
+In addition, discriminants provide a variety of additional ways for dependence.
+There are enough of these that we don't want to enumerate them; 
+that would cause a future language maintenance problem (easy to forget 
+to update a rule like this if some new kind of formal is added).
+End AARM Discussion.
+For each formal type declaration /F/ with a /default_/subtype_mark /S/, after 
+substituting the /default_/subtype_mark for any other formal type of the same 
+generic_formal_part which appears in /F/, /S/ shall be a legal actual for the 
+substituted version of /F/.
+AARM Reason: This rule prevents inconsistent defaults. For example:
+    type Float_Array is (Positive range <>) of Float;
+    generic
+      type Elem is digits <> or use Long_Float;
+      type Arr is array (Positive range <>) of Elem or use Float_Array; -- Illegal.
+An instantiation of this generic using defaulted formal types would be illegal.
+We expect this to be a common usage, so it doesn't make much sense to allow
+a generic that can't be instantiated as it appears to be intended.
+End AARM Reason.
+AARM Discussion: We write the rule this way as we do not want to repeat all of 
+the requirements on actual types here.
 This AI proposes to allow generic formal types to have defaults. Currently,
@@ -118,6 +178,58 @@
 abstractions. A short discussion on comp.lang.ada revealed that several
 developers of container libraries have come across these issues and perceive
 them as shortcomings of Ada 95.
+The consistency checking for default types has to meet two main requirements:
+* We don't want to repeat any of the rules about matching actuals to formals.
+  That would certainly lead to missing some, and other sorts of pestilence.
+* We also don't want to cause implementations to implement lots of new code - 
+  it should be fairly obvious how to implement the checks using existing code.
+We settled on a rule that can "easily" be implemented by the following loop:
+    for Formal_Type of Formal_Part loop
+        if Has_Default (Formal_Type)  then
+           Check_Actual_Against_Formal (Formal_Type, Default_Subtype);
+           Replace_In (Formal_Part, Formal_Type, Default_Subtype);
+        end if;
+    end loop;
+This loop operates on a copy of the formal part (can't modify the original).
+Check_Actual_Against_Formal does all of the checks for an actual type against 
+a formal type in any instance. Replace_In replaces the given formal type with 
+the default subtype in the entire formal part. Since a type can only depend on 
+types preceeding it, this loop will make all of the checks needed, taking into 
+account the default for earlier formal types. Note that the requirement that 
+any dependence formal type has a default ensures that for any type with a
+default, any dependencies also have an actual type. Thus, this check is exactly
+the same as one used for an instance, and thus implementers shouldn't have to
+do too much surgury to make this check.
+The part of the dependence rule about formal packages is talking about a case
+   generic
+      type Elem is digits <> or use Float;
+   package Signature is end Signature;
+      [Editor's note: Sorry, John. ;-)]
+   generic
+       with package Sig is new Signature (<>);
+       type Arr is array (Positive range <>) of Sig.Elem 
+          or use Float_Array; -- Illegal.
+Here, Arr depends on a type from the formal package. We don't allow this, as
+it would be an implied contract on Sig when the default is being used. We also
+want the consistency check to work only on actual types, so having a type
+exported from a formal package that isn't an actual type involved breaks the
+intended check.

Questions? Ask the ACAA Technical Agent