 //
 // 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
 // =====

// property, and they can be provided as methods on the collection,
// for example removeAll(in: Range<Index>) and
// removeAll(_: (Element)->Bool).

infix operator ...* { associativity none precedence 135 }
infix operator ..<* { associativity none precedence 135 }

//    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, 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 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.
//
