[swift-evolution] InternalString class for easy String manipulation
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:
> 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...
More information about the swift-evolution