> On Jan 20, 2017, at 3:08 PM, Sean Heber via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> * The talk about implicit conversions between Substring and String bums me >>> out, even though I see the importance of it in this context and know that >>> it outweighs the alternatives. Given that the Swift team seems to prefer >>> explicit to implicit conversions in general, I would hope that if they feel >>> it's important enough to make a special case for the standard library, it >>> could be a language feature that you'd consider making available to >>> anyone. >> >> Not speaking for the whole team, I personally feel we should make it >> generally available, but I also recognize that we'll likely have to roll >> out the String reimplementation before we have time to properly design >> a general “struct subtyping” feature for end-users. > > I may not be following this properly, but isn’t this sort of situation what > protocols are for? Why couldn’t String be a protocol and there be something > like UnicodeString and UnicodeSubstring and they both implement the String > protocol? >
Protocols + generics are definitely a good way of writing functions that work across strings and substrings, especially in your own code, and especially if it’s a string utility function that would suit an extension of the Unicode protocol (or maybe, once strings are collections, just an extension on Collection). However, it shouldn’t be a requirement of the design that everyone wanting to write a function involving strings should be pushed into making their functions generic. String as the currency type can’t be an existential protocol (or type-erased AnyUnicode-like type) spanning both strings and substrings, though. To do this would obviate the benefit of having two types, since then it would be easy to be passed a Substring without knowing it and then store it long-term, leading to the memory leakage problems described in the doc. > l8r > Sean > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
