<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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. &nbsp;Does one have to subscribe to the verbose (non digest post) in order to respond to a thread correctly? &nbsp;Or is there a link to some instructions? &nbsp; Thanks.<div class=""><br class=""></div><div class="">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. &nbsp;To be clear, the applications need to work and produce correct results and need to be robust in this way. &nbsp;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. &nbsp;I dislike having to scan/read code which has long multiply nested method trains such as&nbsp;</div><div class=""><br class=""></div><div class="">str.characters.count &nbsp; &nbsp; &nbsp;where to me, it is easier to scan/read code such as &nbsp; &nbsp; &nbsp; &nbsp;str.len or len(str)</div><div class=""><br class=""></div><div class="">I understand the need for unicode in general purpose / internationalized applications. &nbsp; However, it is overkill for most of what I need to do. &nbsp;Also, I agree with Michael that learning the unicode way of Swift is a barrier to people new to coding.</div><div class=""><br class=""></div><div class="">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 &nbsp;This could be put into a “semi-standard” library and people who needed/wanted a simplified interface could access and use it? &nbsp;Couldn’t the existing dull underlying string structure be used for this?</div><div class=""><br class=""></div><div class=""><div class="">I also don’t like to have to perform type conversions between floating point numbers but that is for another thread.</div><div class=""><br class=""></div></div><div class="">——</div><div class=""><div><blockquote type="cite" class=""><div class="">On Aug 15, 2016, at 1:00 PM, &nbsp;Michael Savich &lt;<a href="mailto:savichmichael@icloud.com" class="">savichmichael@icloud.com</a>&gt; wrote:</div></blockquote><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 24px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.<span class="Apple-converted-space">&nbsp;</span></span></div></blockquote>&lt;snip&gt;</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Aug 15, 2016, at 8:24 PM,Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>&gt; wrote:</div></blockquote><blockquote type="cite" class="">&lt;snip&gt;</blockquote><blockquote type="cite" class=""><div class=""><span class="" style="float: none; display: inline !important;">But, we also want Swift to support Unicode by default, and we want that&nbsp;</span><span class="" style="float: none; display: inline !important;">support to do things The Right Way(TM) by default. In other words, a user</span><br class=""><span class="" style="float: none; display: inline !important;">should not have to reach for a special type in order to handle arbitrary&nbsp;</span><span class="" style="float: none; display: inline !important;">strings correctly, and I should be able to reassign `a = "你好"` and have&nbsp;</span><span class="" style="float: none; display: inline !important;">things work as expected. So, we also can't have the "easy" string type be&nbsp;</span><span class="" style="float: none; display: inline !important;">the default...</span></div></blockquote></div></div></body></html>