[swift-evolution] Strings in Swift 4

Ben Cohen ben_cohen at apple.com
Mon Jan 23 15:22:53 CST 2017


> On Jan 20, 2017, at 3:08 PM, Sean Heber via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170123/88cc2384/attachment.html>


More information about the swift-evolution mailing list