[swift-evolution] Strings in Swift 4

Dave Abrahams dabrahams at apple.com
Fri Jan 20 09:24:55 CST 2017

Sent from my iPad

> On Jan 19, 2017, at 8:18 PM, Ben Cohen <ben_cohen at apple.com> wrote:
>> On Jan 19, 2017, at 19:38, David Sweeris <davesweeris at mac.com> wrote:
>> Regarding substrings... Instead of having separate `ArraySlice` and `Substring` types, what about having just one type, `Slice<T: Sequence>`, for anything which shares memory? Seems like it'd be easier for users who'd only have to worry about shared storage for one type, and for stdlib authors who'd only have to write it once.
> Collections already do get a default SubSequence implementation of Slice<Base: Indexable> that is essentially like just that. 
> The reason types like Array and String have their own is to customize it with more than the default behavior. For example, ArraySlice provides .withUnsafeBufferPointer  method just like an Array does. Substring would need all the features String provides.
> Now, once we get conditional conformance, we could use that to maybe increase sharing, for example we could create a protocol for types backed by contiguous memory that provided withUnsafeEtc, and then use conditional conformance to add those features to Slice when the Base has them.

We don't need conditional conformance in order to replace ArraySlice with MutableRangeReplaceableRandomAccessSlice<Array>, but to spell that Slice<Array> or generalize withUnsafeXXX to a ContiguouslyStored without adding another in our already-too-large menagerie of slice types, we would.

Substring is different, though: we want to specialize its storage to be able to store code units inline, without using any dynamic memory, so it would need to have a different type from the generic Slice<String>.


More information about the swift-evolution mailing list