Now that we have all the language features we need, I'm working on a proposal to eliminate the
ArraySlice type and replace it with just a compatibility
typealias ArraySlice<T> = Slice<Array<T>> instead. Hopefully this will both simplify the standard library and help make things clearer for users.
To do this, we need to make sure that all the capabilities of
ArraySlice come from protocols rather than methods directly on the type. For example, to give
withUnsafeBufferPointer method, we will need to introduce a
ContiguouslyStored protocol. Then we can write
extension Slice: ContiguouslyStored where Base: ContiguouslyStored. For the most part, this is all good stuff – people often ask for a way to write generic code over different types that have a
withUnsafeBufferPoitner method. But we have to do it this way, too, because you can't write
extension Slice where Base == Array because we don't have parameterized extensions yet.
One challenge that has come up is the
capacity property. This doesn't exist on any protocols today – just concretely on some times like
If we did want to put it on the protocol, the logical one would be
RangeReplaceableCollection, which already has a
reserveCapacity method. It could have a default implementation that returned
count, or maybe zero for non-random-access collections.
But the question is: is
capacity actually useful at all? Are there practical use cases, other maybe than debugging and experimentation, where you need to query the capacity in order to make a decision as part of an algorithm? If not, it could probably be deprecated and dropped from
ArraySlice entirely (and maybe from
Anyone got any use cases out there?