1) Substring is a term of art used universally throughout computing, and camel-casing it would run counter to that.
2) While subsequence is a word, its precise mathematical meaning differs from what it means in Swift. In Swift a SubSequence contains consecutive elements of a sequence, whereas in math a subsequence may contain any subset of the elements, ordered correctly. Hence Subsequence would be technically incorrect (not a big issue IMO).
3) We want Sub[sS]tring and Sub[sS]equence to have the same capitalization.
I'd prefer ignoring 2 and satisfying 1 and 3, since there's no reason Swift's names must exactly coincide with mathematical objects with the same name (for instance, mathematical sets may contain anything at all, including themselves). In addition, the prefix "Sub" does not usually (ever?) produce a Sequence with wholly different mechanics, as do "Enumeration", "Zip2", etc. -- the Subsequence really belongs to the owning Sequence. So my vote is for Substring and Subsequence.
As for why not StringSlice... Substring is certainly a more familiar word. That said, StringSlice would make it clearer that the slice is a view into a String and is meant for temporary use only, which Substring might not convey. If we choose StringSlice, I see no reason to change SubSequence to Subsequence.
So, running with the parallel, why not add a conditional conformance: "Slice: Unicode where Base: Unicode”?
- Karl
···
On 30 Mar 2017, at 21:39, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:
Adrian,
I think there are a few competing claims here.
1) Substring is a term of art used universally throughout computing, and camel-casing it would run counter to that.
2) While subsequence is a word, its precise mathematical meaning differs from what it means in Swift. In Swift a SubSequence contains consecutive elements of a sequence, whereas in math a subsequence may contain any subset of the elements, ordered correctly. Hence Subsequence would be technically incorrect (not a big issue IMO).
3) We want Sub[sS]tring and Sub[sS]equence to have the same capitalization.
I'd prefer ignoring 2 and satisfying 1 and 3, since there's no reason Swift's names must exactly coincide with mathematical objects with the same name (for instance, mathematical sets may contain anything at all, including themselves). In addition, the prefix "Sub" does not usually (ever?) produce a Sequence with wholly different mechanics, as do "Enumeration", "Zip2", etc. -- the Subsequence really belongs to the owning Sequence. So my vote is for Substring and Subsequence.
As for why not StringSlice... Substring is certainly a more familiar word. That said, StringSlice would make it clearer that the slice is a view into a String and is meant for temporary use only, which Substring might not convey. If we choose StringSlice, I see no reason to change SubSequence to Subsequence.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Primarily because this would rule out giving substrings the “small string optimization" where we pack the characters into the struct directly when they’ll fit.
(or rather, given substrings will be 2-3 words, the not-even-that-small string optimization)
···
On Mar 30, 2017, at 2:03 PM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:
So, running with the parallel, why not add a conditional conformance: "Slice: Unicode where Base: Unicode”?
Wait, if you're using the `startIndex` and `endIndex` words for the small substring optimization, how are you keeping the indices interchangeable with the parent string's?
···
On Mar 30, 2017, at 2:42 PM, Ben Cohen via swift-evolution <swift-evolution@swift.org> wrote:
(or rather, given substrings will be 2-3 words, the not-even-that-small string optimization)
(or rather, given substrings will be 2-3 words, the not-even-that-small string optimization)
Wait, if you're using the `startIndex` and `endIndex` words for the small substring optimization, how are you keeping the indices interchangeable with the parent string's?
This will require the indices to know more than just a position in a buffer. It’s not certain this performance trade-off is worth it, being experimented with.
···
On Mar 31, 2017, at 2:00 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
On Mar 30, 2017, at 2:42 PM, Ben Cohen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: