Looking at the String reference again, I see that Swift.String is
subscriptable. Also, I was able to write my “split” function without using
subscripting at all:
public extension String {
public func split(_ pattern :String) -> [String] {
var results = [String]()
var remaining = self.startIndex..<self.endIndex;
while let matchRange = self.range(of:pattern, options:
.regularExpressionSearch, range: remaining, locale: nil) {
results.append(self.substring(with:
remaining.lowerBound..<matchRange.lowerBound))
remaining = matchRange.upperBound..<self.endIndex
}
results.append(self.substring(with:remaining))
return results
}
}
So it seems I’ve painted myself into a corner...
-Kenny
> On Aug 17, 2016, at 1:34 PM, Kenny Leung via swift-evolution
> <[email protected]> wrote:
>
>
>> William Sumner says:
>> Can you be more specific about the improvements you’d like to see? Based on
>> an earlier message, you want to be able to use subscripting on strings to
>> retrieve visual glyphs, but you can do this now via the .characters
>> property, which presents a view of the string’s contents as a collection of
>> extended grapheme clusters.
>
> I did not know about .characters. I would say this addresses the glyph
> portion of my issues.
>
> I still have a problem with not being able to index using simple integers to
> create subscripts or ranges. I wrote my own “split" function, and found it
> extremely frustrating to have to work with .Index types instead of being able
> to use integers for subscripts and ranges. Compared to other languages, this
> almost obviates the usefulness of subscripts altogether. I understand that
> there are performance implications with translating integer subscripts into
> actual indexes in the string, but I guess this is a case where even
> generating another view on the string doesn’t do enough (internally) to make
> it worthwhile. Perhaps if it did… Again, this is very beginner unfriendly. I
> guess I will amend my definition of beginner to not only include people new
> to programming, but people already experienced in languages besides Swift.
> Now that I think about it, NSString is as powerful as Swift.String when ti
> comes to Unicode, and it still allows integer based indexing.
>
> Another issue I have is that a String itself is not subscriptable, but that
> you have to get a view of it. I think String should have some default
> subscriptability that “does the right thing”, whatever that is decided to be.
>
> <heart-to-heart on>
> Now that we’re getting to the heart of the problem (thanks for the prompting
> me to think more deeply about it), Swift may be more frustrating to learn for
> experienced programmers coming from C, Objective-C, Java, Ruby, etc. You try
> to do the simplest think like index into a string, and then find out you
> can’t - you think to yourself, “I’ve been programming in Objective-C for 20
> years. Why can’t I do this? Am I stupid? Is the Swift team purposely trying
> to make this hard for me?”
>
> I’ve been reading swift-evolution for a long time now, and a reason often
> given for design decisions is “term of art”. I believe that integer-based
> subscriptablilty is a term of art that should be supported.
> <heart-to-heart off>
>
>
>> On Aug 17, 2016, at 12:51 PM, Shawn Erickson <[email protected]> wrote:
>>
>> I would also like to understand the perceived problem for first time
>> programmers. To me first time programmers would be working with string
>> literals ("hello world"), string literals with values in them ("Hello
>> /(name)"), doing basic string concat, using higher level API of string to do
>> and find things in a string, etc..
>
> I guess it’s a matter of opinion what features beginner programmers will dip
> their toes into, but I think string manipulation is not that far up the totem
> pole. Would you consider splitting a comma-separated string an advanced task?
>
> Also, see my revised definition of beginner programmer above.
>
> -Kenny
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
