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

Differences between 1.11 and version 1.12
Log of other versions for file ai12s/ai12-0212-1.txt

--- ai12s/ai12-0212-1.txt	2018/03/28 00:45:14	1.11
+++ ai12s/ai12-0212-1.txt	2018/03/30 07:55:08	1.12
@@ -3294,3 +3294,158 @@
 a few of the overly complex examples.
 
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 28, 2018  8:27 PM
+
+> OK, here is another shot at container aggregates, including a section 
+> on generalizing array aggregates.
+
+Thanks. A few thoughts.
+
+(1) I find this better, still not perfect (but when does that happen? :-)
+
+(2) I still dislike using (<>) for empty aggregates, especially when <> means
+something else. I won't belabor this, I've covered it before. [(7) covers one
+possible way to eliminate this objection.]
+
+(3) <> in array and record aggregates means a default-initialized component. 
+Here, you have defined it to mean an empty (uninitialized) slot instead. These
+aren't the same thing! (It's a Bounded Error to read an uninitialized slot; a
+default-initialized element is usable in the normal way.) I use
+default-initialized aggregate items all the time with the explicit intent of
+getting default initialization (typically, so counters/lengths and the like
+are initialized to empty). 
+
+Note that most of the (definite) containers have Insert operations that don't
+take an element and insert a default initialized object. (See, for instance,
+A.18.2(163-165/2)). I don't know that it is worth explicitly using these
+operations, but that fact that they were considered valuable enough to define
+suggests to me at least that <> meaning default-initialization is also
+valuable.
+
+It is clear that <> is only meaningful for definite types (that is a
+requirement of record and array types, not for containers).
+
+So, as an alternative proposal, consider the following outline:
+    * <> is only allowed when the element type is definite;
+    * <> is allowed for any construct in a named aggregate;
+    * For Add_Named, <> is equivalent to the block:
+         declare
+            Elem : Element_Type; -- Default-initialized;
+         begin
+            Add_Named (Container, Key, Elem);
+         end;
+    * For Add_Indexed, <> is equivalent to the block:
+         declare
+            Elem : Element_Type; -- Default-initialized;
+         begin
+            Add_Named (Container, Index, Elem);
+         end;
+    * If Add_Unnamed is needed, it would follow as the above.
+
+We can discuss this further later.
+
+(4) There's some typos in the array iterator proposal: the clause number is
+incorrectly 4.2.3 in a couple of places, and I presume that "Add 4.2.3(20) as
+follows:" should really be "Add after 4.3.3(20):" since I presume you are not
+suggesting to replace 4.3.3(20) [and there is no 4.2.3 anyway].
+
+(5) The wording change (presumably) added after 4.3.3(20) seems a bit more 
+explicit than necessary. Do we have to *require* that the iteration is 
+performed twice? We surely should allow it, but if the compiler can figure
+the length some other way (or is willing/able to use an expandable temporary
+space), shouldn't we allow only a single execution of the iterator? (An as-if
+optimization isn't enough, as one can detect if a container iterator is
+executed.)
+
+In particular, if one uses the array element iterator in this way (surely
+legal), the length can be figured from the array without executing any
+iteration. That is:
+     for E of Some_Array =>
+the compiler can surely figure out how many elements there are without
+executing anything.
+Similarly, for the language-defined containers, the length of the container
+element iterator can be figured by asking the container length without
+iterating anything:
+     for E of Some_Container =>
+The number of elements in this case is always Some_Container.Length for the
+language-defined containers.
+
+This latter optimization would require some magic as it stands (although we
+could define a language-defined enhancement if we wanted to make this a
+standard thing). As an implementor, I'd probably define an
+implementation-defined aspect and specify that with Length. Since iteration
+can be expensive, that would be a better option for these common iterators.
+
+Of course, arbitrary cursor-based iterators would probably require a count.
+For something like:
+    for C in Some_Container.Iterator (From => First, To => Last) loop
+the number of elements is unknown.
+
+(6) I didn't see anything to deal with the 1-element aggregate for containers
+that only define Add_Unnamed. As we all know, there is no single element
+positional aggregate. Containers that only define Add_Unnamed (like lists and
+sets) can't fall back on named notation, as there are no names to use.
+
+The only solution in the current AI is to use some sort of iterator:
+
+         (for I in 1 .. 1 => The_Element)
+
+If users think that saying "(1 .. 0 => The_Component)" is annoying for the
+rarely-used null array aggregate, they ought to scream bloody murder for being
+forced to write the above.
+
+I'm definitely against defining any empty aggregate if we don't fix this
+problem, as single element lists seem a lot more likely to me than empty
+lists. If you have to use a function to sensibly create the single element
+lists, then there cannot be any worse hardship to do the same for the less
+likely empty lists. (That is, there isn't much point in plugging one hole if
+we leave a worse one.)
+
+I would personally prefer to add the missing functions to List and Set to 
+create one-element lists and forget anything about empty aggregates (here and
+for null arrays), but I'd be happy to figure better solutions.
+
+(7) One wild thought I just had was that we don't really need an Empty
+parameter to the Aggregate aspect -- all of the language-defined containers 
+require the default-initialized container to be "empty". If we simply said
+that the container object is default-initialized, this would mean "empty" for
+the language-defined containers, then (<>) would actually mean a default
+initialized container -- which would eliminate my primary objection to using
+the notation for an empty container aggregate. (Sorry, this doesn't work for
+other aggregates -- <> only is meaningful for definite types.) It also would
+simplify the semantics description slightly - one less subprogram to check and
+describe rules for.
+
+A user-defined container that wanted to use the aggregate notation would have
+to define the default-initialized state to be something useful as the start of
+a container. Perhaps I'm lacking imagination here, but I can't see a sensible
+way for a container to start with elements in it (where would they come from?)
+and still have adding elements be particularly meaningful. So this suggestion
+would reduce the flexibility a bit, but probably wouldn't make much difference
+in practice.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 28, 2018  8:57 PM
+
+>> OK, here is another shot at container aggregates, including a section 
+>> on generalizing array aggregates.
+> 
+> Thanks. A few thoughts. ...
+
+Thanks, all good comments, and no particular responses at this point.  It
+feels like we are on the same wavelength, even if some of the details might
+be up for debate.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 28, 2018  9:14 PM
+
+Comments are welcome; I can justify debating this proposal's details much 
+more easily than anything involving rarely-used contracts. ;-)
+
+****************************************************************

Questions? Ask the ACAA Technical Agent