[swift-evolution] InternalString class for easy String manipulation

Richard Ward roward at mac.com
Sun Aug 21 15:04:13 CDT 2016

First, this is my first post to a list like this and I could not find the instructions to properly respond to a post in the digest.  Does one have to subscribe to the verbose (non digest post) in order to respond to a thread correctly?  Or is there a link to some instructions?   Thanks.

I come from a scientific/engineering background where I create a lot of utility applications which do not have to be as robust in certain ways as commercial applications which are used by a mass number of people.  To be clear, the applications need to work and produce correct results and need to be robust in this way.  Python is used by a large portion of the scientific community to create applications such as I mentioned and in large part due to what Michael stated in his original email.  I dislike having to scan/read code which has long multiply nested method trains such as 

str.characters.count      where to me, it is easier to scan/read code such as        str.len or len(str)

I understand the need for unicode in general purpose / internationalized applications.   However, it is overkill for most of what I need to do.  Also, I agree with Michael that learning the unicode way of Swift is a barrier to people new to coding.

I am wondering why one can’t make a method extension for String called .len or .length (and for that case make a commonly used subscript extension as well) which conform to a protocol which is constructed as only taking say ascii or simplified string?s  This could be put into a “semi-standard” library and people who needed/wanted a simplified interface could access and use it?  Couldn’t the existing dull underlying string structure be used for this?

I also don’t like to have to perform type conversions between floating point numbers but that is for another thread.

> On Aug 15, 2016, at 1:00 PM,  Michael Savich <savichmichael at icloud.com <mailto:savichmichael at icloud.com>> wrote:
> Back in Swift 1.0, subscripting a String was easy, you could just use subscripting in a very Python like way. But now, things are a bit more complicated. I recognize why we need syntax like str.startIndex.advancedBy(x) but it has its downsides. Namely, it makes things hard on beginners. If one of Swift's goals is to make it a great first language, this syntax fights that. Imagine having to explain Unicode and character size to an 8 year old. This is doubly problematic because String manipulation is one of the first things new coders might want to do. 

> On Aug 15, 2016, at 8:24 PM,Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
> <snip>
> But, we also want Swift to support Unicode by default, and we want that support to do things The Right Way(TM) by default. In other words, a user
> should not have to reach for a special type in order to handle arbitrary strings correctly, and I should be able to reassign `a = "你好"` and have things work as expected. So, we also can't have the "easy" string type be the default...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160821/4685dca6/attachment.html>

More information about the swift-evolution mailing list