On Wed, Dec 16, 2015 at 12:05 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 12/15/15, Ben Coman <btc at openinworld.com> wrote:
>> On Thu, Dec 10, 2015 at 12:37 AM, Todd Blanchard <tblanchard at mac.com>
>> wrote:
>>> They are practically the same thing.
>>>
>>> ICU was developed by Taligent which was a joint venture between Apple and
>>> IBM.  Makes sense that NSString and ICU's UnicodeString are pretty close
>>> in implementation.  ICU was also ported to Java for Sun by IBM.  The point
>>> is - this is a very elaborate chunk of code with far reach. If ICU is
>>> wrong on some point - it is universally wrong and thus likely to be taken
>>> as "right" as it is at least consistent.  I think re-implementing it is
>>> folly TBH.  Just use it.
>>
>> Apple seem to have moved on from NSString to support Unicode in a
>> different way in Switft...
>
> Could you please give some more details?

http://oleb.net/blog/2014/07/swift-strings/
"Swift's change has the potential to prevent many common errors when
dealing with string lengths or substrings. It is a huge difference to
most other Unicode-aware string libraries (including NSString) where
the building blocks of a string are usually UTF-16 code units or
single Unicode scalars"

cheers -ben

>
> I have read
> https://www.objc.io/issues/9-strings/unicode/#nsstring-and-unicode
> so far.
>
> It says that an NSString object actually represents an array of
> UTF-16-encoded code units.
>
> This in contrast to Squeak / Pharo where a String is an
> ArrayedCollection of 21 bit Unicode code points (transparently
> optimizing to a ByteArray if the string only contains values of the
> first code page).
>
>
>>>
>>>> On Dec 8, 2015, at 15:52, EuanM <euanmee at gmail.com> wrote:
>>>>
>>>> Equally old are the NextStep Object C functions which are now embodied
>>>> within MacOS X.
>>>>
>>>
>>>
>>
>>
>