> • Because Swift is unable to express conditional protocol conformances, > implementing this change has required us to create a great deal of complexity > in the standard library API. Aside from the two excess “Countable” range > types, there are new overloads for slicing and twelve distinct slice types > that capture all the combinations of traversal, mutability, and > range-replaceability. While these costs are probably temporary, they are very > real in the meantime.
Is there a migration strategy possible for when we do support conditional conformances? Would typealiasing the existing names to refinements of a more general Slice<T> type be sufficient? -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
