<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2017, at 3:08 PM, Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">* The talk about implicit conversions between Substring and String bums me<br class="">out, even though I see the importance of it in this context and know that<br class="">it outweighs the alternatives. Given that the Swift team seems to prefer<br class="">explicit to implicit conversions in general, I would hope that if they feel<br class="">it's important enough to make a special case for the standard library, it<br class="">could be a language feature that you'd consider making available to<br class="">anyone.<br class=""></blockquote><br class="">Not speaking for the whole team, I personally feel we should make it<br class="">generally available, but I also recognize that we'll likely have to roll<br class="">out the String reimplementation before we have time to properly design<br class="">a general “struct subtyping” feature for end-users.<br class=""></blockquote><br class="">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?<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>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 <i class="">everyone</i> wanting to write a function involving strings should be pushed into making their functions generic.</div><div><br class=""></div><div>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.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">l8r<br class="">Sean<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>