CollectionsMoveIndices: expand the comment about trees

Author: gribozavr

test/Prototypes/CollectionsMoveIndices.swift

@@ -100,6 +100,10 @@
 // 2. We can't specify constraints on associated types.  This forces many
 //    trivial algorithms to specify useless constraints.
 //
+//    Solution: constraints on associated types are a desirable
+//    language feature, part of the Swift generics model.  This issue
+//    will be fixed by compiler improvements.
+//
 // Trees
 // =====
 //
@@ -150,18 +154,26 @@
 //    reuse, then the tree nodes can't have parent pointers (a node
 //    can have multiple different parents in different trees).  This
 //    means that it is not possible to advance an index in O(1).  If
-//    we need to go up the tree while advancing the index, we would
-//    need to traverse the tree starting from the root in O(log n).
+//    we need to go up the tree while advancing the index, without
+//    parent pointers we would need to traverse the tree starting from
+//    the root in O(log n).
+//
 //    Thus, index has to essentially store a path through the tree
 //    from the root to the node (it is usually possible to encode this
 //    path in a 64-bit number).  Since the index stores the path,
 //    subscripting on such an index would also cost O(log n).
 //
-//    We should note that even though the operations mentioned cost
-//    O(log n), the base of the logarithm would be typically large
-//    (e.g., 32), and the size of the machine memory is limited.
-//    Thus, we could treat the complexity as effectively constant for
-//    all practical purposes.
+//    We should note that persistent trees typically use B-trees, so
+//    the base of the logarithm would be typically large (e.g., 32).
+//    We also know that the size of the RAM is limited.  Thus, we
+//    could treat the O(log n) complexity as effectively constant for
+//    all practical purposes.  But the constant factor will be much
+//    larger than in other designs.
+//
+//    Swift's collection index model does not change anything as
+//    compared to other languages.  The important point is that the
+//    proposed index model allows such implementations of persistent
+//    collections.
 //
 // 2. Trees with O(1) subscripting and advancing.
 //
@@ -208,13 +220,35 @@
 //        extra data structure would only increase the constant factor
 //        on memory overhead.
 //
+//                                      | (1)      | (2)(a)  | (2)(b)
+// -------------------------------------+----------+---------+-------
+//                          memory-safe | Yes      | Yes     | Yes
+//    indices are not reference-counted | Yes      | Yes     | Yes
+//                         shares nodes | Yes      | No      | No
+//             subscripting on an index | O(log n) | O(1)    | O(1)
+//                   advancing an index | O(log n) | O(1)    | O(1)
+// deleting does not invalidate indices | No       | No      | Yes
+// requires extra O(n) storage just ... |          |         |
+//                    for safety checks | No       | No      | Yes
+//
 // Each of the designs discussed above has its uses, but the intuition
 // is that (2)(a) is the one most commonly needed in practice.  (2)(a)
 // does not have the desired index invalidation properties.  There is
 // a small number of commonly used algorithms that require that
 // property, and they can be provided as methods on the collection,
 // for example removeAll(in: Range<Index>) and
 // removeAll(_: (Element)->Bool).
+//
+// If we were to allow reference-counted indices (basically, the
+// current collections model), then an additional design is possible
+// -- let's call it (2)(c) for the purpose of discussion.  This design
+// would be like (2)(b), but won't require extra storage that is used
+// only for safety checks.  Instead, every index would pay a RC
+// penalty and carry a strong reference to the tree node.
+//
+// Note that (2)(c) is still technically possible to implement in the
+// new collection index model, it just goes against a goal of having
+// indices free of reference-counted stored properties.
 
 infix operator ...* { associativity none precedence 135 }
 infix operator ..<* { associativity none precedence 135 }