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

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

--- ai12s/ai12-0205-1.txt	2016/11/24 02:41:08	1.2
+++ ai12s/ai12-0205-1.txt	2018/12/07 05:15:37	1.3
@@ -1,83 +1,100 @@
-!standard 12.4 (6)                                    16-10-06  AI12-0205-1/01
-!standard 12.5 (2)
-!standard 12.7 (2)
+!standard 12.3(7/3)                                  18-12-06  AI12-0205-1/02
+!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 work item 16-10-06
 !status received 16-10-06
 !priority Medium
 !difficulty Medium
-!subject Defaults for generic formal parameters
+!subject Defaults for generic formal types
 
 !summary
 
-The syntax of generic formal type, package, and "in out" object parameters are
-modified to permit default expressions.
+The syntax of generic formal type parameters is modified to permit
+default subtypes to be specified.
 
 !problem
 
-Ada 2012 does not have defaults for generic formal types or packages. While
-not a serious problem (users can always be forced to supply explicit values
-for all parameters), it is sometimes a nuisance and unnecessarily complicates
-some generic instantiations. Allowing more kinds of defaults for generic
-formal parameters can significantly ease the use of generic units.
+Ada 2012 does not have defaults for generic formal types, packages, or
+objects of mode "in out". While not a serious problem (users can always
+be forced to supply explicit values for all parameters), it is sometimes
+a nuisance and unnecessarily complicates some generic instantiations.
+Allowing more kinds of defaults for generic formal parameters can
+significantly ease the use of generic units. This AI proposes a means
+of specifying defaults for generic formal types. Defaults for formal
+packages and formal objects of mode "in out" are proposed in a separate
+AI (see AI12-0297-1).
 
 !proposal
 
-Defaults for generic formal types
----------------------------------
+[NOTE: Now that !wording is added, maybe this section should be changed
+to read simply "(See !summary.)"?]
 
-12.5(2) is modified to read
+12.5(2.1-2.2) is modified to read
 
-  formal_type_declaration ::=
-    type defining_identifier [discriminant_part] is
-      formal_type_definition [or use default_subtype_mark];
+  formal_complete_type_declaration ::=
+    type defining_identifier[discriminant_part] is formal_type_definition
+      [or use \default_\subtype_mark] [aspect_specification];
 
-The optional "or use subtype_mark" defines a default type
-to be used if an instantiation does not explicitly provide an actual
-for that parameter. 12.3(7 and 10) are modified to include default_subtype_mark
-as an option for missing parameter associations. (Note: "default_" is in
-italics in default_subtype_mark.) The subtype denoted by default_subtype_mark
-must fulfill all the constraints/rules as if it occurred as a
-generic actual in a generic parameter association.
+  formal_incomplete_type_declaration ::=
+    type defining_identifier[discriminant_part] [is tagged]
+      [or use \default_\subtype_mark];
 
+The optional "or use subtype_mark" defines a default type to be used if
+an instantiation does not explicitly provide an actual for that parameter.
+12.3(7 and 10) are modified to include \default_\subtype_mark as an option
+for missing parameter associations. (Note: "default_" is in italics in
+\default_\subtype_mark.) The subtype denoted by \default_\subtype_mark must
+fulfill all the constraints/rules as if it occurred as a generic actual
+in a generic parameter association.
 
-Defaults for generic formal packages
-------------------------------------
+!wording
 
-12.7 (2) is modified to read
+Modify 12.3(7/3) as follows:
 
-  formal_package_declaration ::=
-    with package defining_identifier is
-      new generic_package_name formal_actual_part [or use default_package_name];
+The generic actual parameter is either the explicit_generic_actual_parameter
+given in a generic_association for each formal, or the corresponding
+default_expression{, \default_\subtype_mark,} or default_name if no
+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.
 
-The optional "or use package_name" defines a default package
-to be used if an instantiation does not explicitly provide an actual
-for that parameter. 12.3(7 and 10) are modified to include default_package_name
-as an option for missing parameter associations. (Note: "default_package_" is
-in italics in default_package_name.) The package denoted by default_package_name must
-be an instantiation of the generic package denoted by generic_package_name
-such that it fulfils the constraints imposed by the formal_actual_part.
+Modify 12.3(10) as follows:
 
+A generic_instantiation shall contain at most one generic_association
+for each formal. Each formal without an association shall have a
+default_expression{, \default_\subtype_mark,} or subprogram_default.
 
-Defaults for generic formal "in out" objects
---------------------------------------------
+Replace 12.5(2.1-2.2/3):
 
-It is proposed to delete paragraph 12.4(6). This will allow generic formal
-"in out" objects to have default expressions.
+  formal_complete_type_declaration ::=
+    type defining_identifier[discriminant_part] is formal_type_definition
+      [or use \default_\subtype_mark] [aspect_specification];
 
+  formal_incomplete_type_declaration ::=
+    type defining_identifier[discriminant_part] [is tagged]
+      [or use \default_\subtype_mark];
 
+Add after 12.5(7/2):
+
+The \default_\subtype_mark, if any, shall denote a subtype in the category
+determined for the formal type.
+
 !discussion
 
-The basic idea behind these changes is to allow all types of generic
-parameters to have defaults. Currently, only subprograms and 'in' objects
-may have a default value. However, the benefits of default parameters can exist
-for any kind of parameter.
-
-All of these changes aim at making generic instantiations simpler to write,
-or rather, to give designers of generic units the means to design their
-units such that instantiations can be made simpler than today. It is often
-possible to supply reasonable default values for some of the entities to
-which the above proposal applies.
+This AI proposes to allow generic formal types to have defaults. Currently,
+only subprograms and 'in' objects may have a default value. However, the
+benefits of default parameters can exist for any kind of parameter. The
+possibility of defaults for formal packages and formal objects of mode
+"in out" is proposed in a separate AI (see AI12-0297-1).
+
+The aim is to make generic instantiations simpler to write, or rather,
+to give designers of generic units the means to design their units such
+that instantiations can be made simpler than today. In the case of generic
+formal types, it is often possible to supply a reasonable default subtype.
 
 The syntax for default types is hard to define. 'Or use' was selected because
 a default type is an alternative to specifying an actual type. We also
@@ -100,12 +117,8 @@
 developers of container libraries have come across these issues and perceive
 them as shortcomings of Ada 95.
 
-
 !example
 
-An example for defaults for generic formal types
-------------------------------------------------
-
 Consider a list container with an operation returning the number of items
 currently in the list.
 
@@ -190,131 +203,9 @@
 end Lists;
 
 
-An example for defaults for generic formal packages
----------------------------------------------------
-
-Consider a hash table container abstraction using a signature
-package for the key type:
-
-  generic
-     type Key_Type (<>) is private;
-     with function Hash (Key : in Key_Type) return Natural;
-     with function "=" (L, R : in Key_Type) return Boolean is <>;
-  package Hashable is
-     -- Signature package.
-  end Hashable;
-
-  generic
-     with package Keys is new Hashable (<>);
-     type Item_Type (<>) is private;
-     Initial_Default_Size : Positive := 23;
-  package Hash_Tables is
-
-     type Hash_Table is private;
-
-     procedure Insert
-       (Table : in out Hash_Table;
-        Key   : in     Keys.Key_Type;
-        Item  : in     Item_Type);
-
-     -- ... Other operations on hash tables
-
-  end Hash_Tables;
-
-Then, one could get a package for hash tables with strings as keys as
-follows:
-
-  with Hash_Support;
-  package String_Keys is
-     new Hashable (Key_Type => String, Hash => Hash_Support.Hash_String);
-
-  generic
-     with package Keys is new Hashable (<>) or use String_Keys; -- New syntax.
-     type Item_Type (<>) is private;
-     Initial_Default_Size : Positive := 23;
-  package String_Hash_Tables is
-     package Table is Hash_Tables (Keys, Item_Type, Initial_Default_Size);
-     -- Probably would use renames here to make the contents directly visible.
-  end String_Hash_Tables;
-
-with the same instantiations for finally getting concrete hash tables:
-
-  package My_Hash_Tables is
-    new String_Hash_Tables (Item_Type => My_Data);
-
-  package My_Other_Hash_Tables is
-    new String_Hash_Tables (Item_Type => My_Other_Data);
-
-
-An example for defaults for generic formal "in out" objects
------------------------------------------------------------
-
-The motivating example for default values for generic formal
-"in out" objects is the storage pool parameter often found in container
-libraries:
-
-  generic
-     type Item_Type is private;
-     with function "=" (L, R : in Item_Type) return Boolean is <>;
-     Pool : in out System.Storage.Root_Storage_Pool'Class;
-  package Lists is
-
-     type List is private;
-
-     --  Operations on lists...
-
-  private
-
-     type Node;
-     type Link is access all Node;
-     for Link'Storage_Pool use Pool;
-
-     type Node is
-       record
-          Data       : Item_Type;
-          Next, Prev : Link;
-       end record;
-
-     type List is new Ada.Finalization.Controlled with
-       record
-          Head, Tail : Link;
-       end record;
-
-  end Lists;
-
-Many users just don't care about storage pools (or even don't know what they
-are be good for). Advanced users, however, may well want to specify the pool
-in which the list should allocate its nodes, hence adding the pool as a generic
-formal parameter clearly makes sense. Unfortunately, it confuses less advanced
-users (and generally complicates instantiation in those cases where one really
-doesn't care).
-
-If one could provide a default value for "Pool", this confusion or complication
-could be avoided: we could simply declare the package as
-
-  generic
-     type Item_Type is private;
-     with function "=" (L, R : in Item_Type) return Boolean is <>;
-     Pool : in out System.Storage.Root_Storage_Pool'Class := The_Default_Pool;
-  package Lists is
-     ...
-
-[For this example, we won't define what "The_Default_Pool" actually might be.
-For many implementations, a possible declaration might be a pre-written pool
-that just uses the standard pool of some arbitrary access type.]
-
-With defaults for generic formal "in out" objects, an instantiation of this
-list package can be as simple as
-
-  package My_Lists is new Lists (My_Type);
-
-Inexperienced users or users that chose not to care about storage pools can
-use the package without extra hassles, while experienced or concerned users
-still have the possibility to provide their own storage pool.
-
 !ASIS
 
-** Unknown ASIS effect **
+** TBD: with new syntax, new/modified ASIS queries will be needed.
 
 !ACATS test
 
@@ -787,7 +678,7 @@
 
 >> This is torturing the meaning of aspects a bit, in my view.
 >
-> We already have Default_Value and Default_Component_Value aspects. 
+> We already have Default_Value and Default_Component_Value aspects.
 > Jeff's idea seems similar to those, so it doesn't seem *that* tortured.
 
 Good point, but it somehow still feels pretty different.  The presence of an
@@ -795,8 +686,8 @@
 Whereas for Default_Value, it affects the run-time semantics, but not legality
 (except in some Baird-ian corner of corner cases, perhaps ;-).
 
-> As I noted in my other message, I'd rather try some very different 
-> syntax, because we already know that any of the six previous proposals 
+> As I noted in my other message, I'd rather try some very different
+> syntax, because we already know that any of the six previous proposals
 > are very unlikely to fly.
 
 Perhaps, though sometimes things can look better on a second iteration. So I
@@ -809,10 +700,10 @@
 From: Randy Brukardt
 Sent: Monday, October 3, 2016  4:13 PM
 
-At the risk of beating a dead horse, I said: 
+At the risk of beating a dead horse, I said:
 
 ...
-> "use" by itself doesn't work, because it is much too close to other, 
+> "use" by itself doesn't work, because it is much too close to other,
 > unrelated syntax:
 ...
 
@@ -857,11 +748,11 @@
 Sent: Monday, October 3, 2016  4:31 PM
 
 > is only one character from:
-> 
+>
 >    generic
 >       with package Pool is new Pools (<>); use Global_Pool;
 >    package Some_Container is
-> 
+>
 > which is 100% legal and means something completely different.
 
 But I don't see how that can cause a run-time bug.  And if it doesn't cause
@@ -887,21 +778,21 @@
 Sent: Monday, October 3, 2016  4:52 PM
 
 > > is only one character from:
-> > 
+> >
 > >    generic
 > >       with package Pool is new Pools (<>); use Global_Pool;
 > >    package Some_Container is
-> > 
+> >
 > > which is 100% legal and means something completely different.
-> 
-> But I don't see how that can cause a run-time bug.  And if it doesn't 
+>
+> But I don't see how that can cause a run-time bug.  And if it doesn't
 > cause run-time bugs, it's not a significant problem.
 
 ??? Nothing that happens at compile-time can be a significant problem? Why do
 we worry about ripple effects and the like???
- 
-> I agree we should try to come up with the best syntax we can, but "We 
-> can't find the perfect syntax" is a pretty poor excuse not to fix a 
+
+> I agree we should try to come up with the best syntax we can, but "We
+> can't find the perfect syntax" is a pretty poor excuse not to fix a
 > rather glaring inconsistency.
 
 Well, it was enough in 2002. Specifically, it was "we can't find appropriate
@@ -912,14 +803,14 @@
 
 >     with package Pool is new Pools (<>) or use Global_Pool;
 >     with package Pool is new Pools (<>) or else use Global_Pool;
-> 
+>
 > ?
 
 Well, I didn't try those (only without the "or").
 
-> I agree with Tuck that using aspects feels wrong, because it's 
-> inconsistent -- other defaults use syntax.  But I'd rather use aspects 
-> than lose the feature.  It's even more inconsistent that some kinds of 
+> I agree with Tuck that using aspects feels wrong, because it's
+> inconsistent -- other defaults use syntax.  But I'd rather use aspects
+> than lose the feature.  It's even more inconsistent that some kinds of
 > generic formals can have defaults, but others can't.
 
 I agree, but this is something that should have been fixed in Ada 2005. It's
@@ -935,13 +826,13 @@
 From: Ed Schonberg
 Sent: Monday, October 3, 2016  5:14 PM
 
-> I agree, but this is something that should have been fixed in Ada 
-> 2005. It's hard to care anymore, since portable Ada has to be limited 
-> pretty much to Ada 2005, and I don't know that will change soon. (And 
-> even if it does, it probably will only be to Ada 2012.) The more stuff 
-> that we layer on, the less likely that non-GNAT compilers ever 
-> implement any of it. (Outside of Janus/Ada, other implementers seem to 
-> take these versions as a lump, which is a sure-fire way never to get 
+> I agree, but this is something that should have been fixed in Ada
+> 2005. It's hard to care anymore, since portable Ada has to be limited
+> pretty much to Ada 2005, and I don't know that will change soon. (And
+> even if it does, it probably will only be to Ada 2012.) The more stuff
+> that we layer on, the less likely that non-GNAT compilers ever
+> implement any of it. (Outside of Janus/Ada, other implementers seem to
+> take these versions as a lump, which is a sure-fire way never to get
 > anywhere.)
 
 Iterated component associations, @ as an abbreviation for left-hand sides, and
@@ -961,7 +852,7 @@
 question of *which* Ada language? The one that can be used without vendor
 lock-in, or the bleeding edge, or something else.
 
-So I'm frustrated about the lack of Ada compiler alternatives, and I worry 
+So I'm frustrated about the lack of Ada compiler alternatives, and I worry
 about loading up too much for anyone else to ever follow. (I'm getting about
 10% of each version implemented before the next one comes out. Not very
 useful.) Taking that frustration out on this proposal is kinda silly,
@@ -980,13 +871,13 @@
 From: Tucker Taft
 Sent: Monday, October 3, 2016  9:18 PM
 
->> I agree with Tuck that using aspects feels wrong, because it's 
->> inconsistent -- other defaults use syntax.  But I'd rather use 
->> aspects than lose the feature.  It's even more inconsistent that some 
+>> I agree with Tuck that using aspects feels wrong, because it's
+>> inconsistent -- other defaults use syntax.  But I'd rather use
+>> aspects than lose the feature.  It's even more inconsistent that some
 >> kinds of generic formals can have defaults, but others can't.
 >
-> I agree, but this is something that should have been fixed in Ada 
-> 2005. It's hard to care anymore, since portable Ada has to be limited 
+> I agree, but this is something that should have been fixed in Ada
+> 2005. It's hard to care anymore, since portable Ada has to be limited
 > pretty much to Ada 2005, and I don't know that will change soon.
 
 Be that as it may, AdaCore has many customers who are using Ada2012 features,
@@ -996,7 +887,7 @@
 open-source, free "GPL" version of the compiler helps them feel that even if
 AdaCore goes up in smoke, the compiler will live on.
 
-> ... The more stuff that we layer on, the less likely that non-GNAT 
+> ... The more stuff that we layer on, the less likely that non-GNAT
 > compilers ever implement any of it.
 
 If we were truly worried about this, we would have stopped working on Ada long
@@ -1017,10 +908,10 @@
 Sent: Monday, October 3, 2016  9:36 PM
 
 ...
-> > ... The more stuff that we layer on, the less likely that non-GNAT 
+> > ... The more stuff that we layer on, the less likely that non-GNAT
 > > compilers ever implement any of it.
-> 
-> If we were truly worried about this, we would have stopped working on 
+>
+> If we were truly worried about this, we would have stopped working on
 > Ada long ago.
 
 That seems pretty extreme. Ada 2005 got implemented by a number of vendors, so
@@ -1029,16 +920,16 @@
 (Note that I am convinced that most of the changes in Ada 2012 are
 sufficiently for the good; the question mainly is going forward.)
 
-> ...  The fact that GNAT is the only Ada compiler keeping up with the 
-> language standard at the moment is not the end of the world.  If you 
-> look at other programming languages, it is not uncommon that there is 
-> one preeminent compiler/front end that really keeps up with the 
-> language standard, while the others lag behind but nevertheless serve 
+> ...  The fact that GNAT is the only Ada compiler keeping up with the
+> language standard at the moment is not the end of the world.  If you
+> look at other programming languages, it is not uncommon that there is
+> one preeminent compiler/front end that really keeps up with the
+> language standard, while the others lag behind but nevertheless serve
 > some special niche of the market (e.g.
 > high performance, open-source, educational version, etc.).
-> 
-> In any case, we should try to apply these sort of "complexity" 
-> criteria uniformly.  We shouldn't just use them to shoot down a 
+>
+> In any case, we should try to apply these sort of "complexity"
+> criteria uniformly.  We shouldn't just use them to shoot down a
 > proposal we don't happen to like.
 
 I agree. Have you seen me support much other than the smallest fixes and stuff
@@ -1055,3 +946,99 @@
 
 ****************************************************************
 
+From: Gary Dismukes
+Sent: Thursday, December 6, 2018  4:22 PM
+
+This AI [this is version /02 of the AI - Editor] has been revised to restrict
+it to define defaults only for generic formal types.  As decided at the
+previous ARG meeting, the other default features (defaults for formal packages
+and formal "in out" objects) are being moved to a separate AI.  This revision
+adds !wording and makes small changes to other sections.  I plan
+to send a draft of the other AI by the 5 pm CST deadline today (or
+at worst shortly past...), but without adding !wording for that one.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 6, 2018  11:13 PM
+
+...
+> !summary
+> 
+> The syntax of generic formal type parameters is modified to permit 
+> default subtypes to be specified.
+
+Perhaps a better summary would not talk about the "syntax" ('cause the 
+semantics is more important!) and would just say:
+
+Generic formal type parameters are modified to permit default subtypes to be 
+specified.
+
+I realize you inherited this one.
+
+> !problem
+> 
+> Ada 2012 does not have defaults for generic formal types, packages, or 
+> objects of mode "in out". While not a serious problem (users can 
+> always be forced to supply explicit values for all parameters), it is 
+> sometimes a nuisance and unnecessarily complicates some generic instantiations.
+> Allowing more kinds of defaults for generic formal parameters can 
+> significantly ease the use of generic units. This AI proposes a means 
+> of specifying defaults for generic formal types. Defaults for formal 
+> packages and formal objects of mode "in out" are proposed in a 
+> separate AI (see AI12-0xxx?).
+
+The other AI is now numbered AI12-0297-1; I made this correction (two places).
+
+> 
+> !proposal
+> 
+> [NOTE: Now that !wording is added, maybe this section should be 
+> changed to read simply "(See !summary.)"?]
+
+I definitely wouldn't repeat the syntax here. But John would complain about 
+"See Summary", especially if the summary talks about the syntax and has almost
+no info about the actual proposal. Perhaps a middle ground would be to talk 
+about the concept of a default type a bit. In any case, the existing !proposal
+should go, 'cause it just repeats the !wording.
+
+> !wording
+> 
+> Modify 12.3(7) as follows:
+> 
+> The generic actual parameter is either the 
+> explicit_generic_actual_parameter given in a generic_association for 
+> each formal, or the corresponding default_expression{, 
+> default_subtype_mark,} or default_name if no 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.
+
+You want "default_" to be in italics here, so that needs to be marked somehow 
+(usually backslashs/slashs/stars). Else the editor is likely to fail to notice
+that and get a pile of errors from tools. I fixed this throughout the AI.
+
+...
+> Replace 12.5(2.1-2.2):
+
+We put the version number in these paragraph numbers, so /3 needs to be added 
+here. Fixed that.
+
+> Add after 12.5(7):
+
+And /2 here.
+ 
+...
+> !ASIS
+> 
+> ** Unknown ASIS effect **
+
+There's new syntax here, so this should say something like:
+
+** TBD: with new syntax, new/modified ASIS queries will be needed.
+
+...which I did. (Not that this is likely to ever matter. We'll probably drop 
+these sections in AI20s once we start working on those.)
+
+****************************************************************

Questions? Ask the ACAA Technical Agent