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

//        extra data structure would only increase the constant factor
//        on memory overhead.
//
// 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

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