Sent from my iPad
> On Jan 19, 2017, at 8:18 PM, Ben Cohen <[email protected]> wrote: > > >> On Jan 19, 2017, at 19:38, David Sweeris <[email protected]> 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>. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
