[swift-corelibs-dev] Bring NSString functions to String

[Tony Parker]

> On May 10, 2017, at 4:19 AM, Andrey Fidrya via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Hi All,
> 
> Btw, when migrating from NSString's methods to URL I've noticed
> that they work a bit differently: URL's methods convert strings
> from NFC to NFD (decomposed) unicode form which is demonstrated
> by the example below.
> 
> I had to additionally call .precomposedStringWithCanonicalMapping
> on resulting string to convert it back to NFC form.
> 
> This was very surprising as it wasn't mentioned anywhere in docs
> and has broken non-english filename support in app.

Out of curiosity, can you explain how this breaks your non-english filename support? What OS and filesystem are you using?

- Tony

> Is this expected behavior or a bug?
> 
> //let source = "/my_file.txt"
> let source = "/мой_файл.txt" // problematic is letter 'й'
> 
> let disallowedCharacters = CharacterSet(charactersIn: source).inverted
> 
> 
> do {
>     print("--- NSString:")
>     let result = (source as NSString).deletingPathExtension as String
>     print(result)
>     print(result.rangeOfCharacter(from: disallowedCharacters))
> 
> }
> 
> do {
>     print("--- String + URL:")
>     let result = URL(fileURLWithPath: source).deletingPathExtension().path
>     print(result)
>     print(result.rangeOfCharacter(from: disallowedCharacters))
>     print(result.precomposedStringWithCanonicalMapping.rangeOfCharacter(from: disallowedCharacters))
> }
> 
> 
> --- Output:
> 
> --- NSString:
> /мой_файл
> nil
> --- String + URL:
> /мой_файл
> Optional(Range(Swift.String.CharacterView.Index(_base: Swift.String.UnicodeScalarView.Index(_position: 3), _countUTF16: 2)..<Swift.String.CharacterView.Index(_base: Swift.String.UnicodeScalarView.Index(_position: 4), _countUTF16: 1)))
> nil
> 
> 
> Regards,
> Andrey
> 
>> On 10 May 2017, at 12:45, Eric Blachère via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>> 
>> Thanks for the answer ! It seems a bit weird from them to advocate using NSString methods in the unavailability comment. I would rather use URL when I can even if the conversions are a bit tedious ^^
>> 
>> Thanks a lot,
>> Eric
>> 
>> 2017-05-10 10:52 GMT+02:00 Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>>:
>> > On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>> >
>> > I was just wondering if there are plans to bring NSString functions manipulating paths into the native String class. (such as lastPathComponent, pathComponents etc...)
>> > Because even if we can always make an extension of String to easily cast it into NSString, it's still a bit of a shame to have to do it ;)
>> 
>> Unfortunately, it seems like the decision not to include these methods on String was quite deliberate.
>> 
>> Here's the revision where that happened: <https://github.com/apple/swift/commit/1f2390f1c75be65f57f189247bfe4f9b2fc11e3b#diff-d38f60064c3752f096c043e756d8f201R925 <https://github.com/apple/swift/commit/1f2390f1c75be65f57f189247bfe4f9b2fc11e3b#diff-d38f60064c3752f096c043e756d8f201R925>> As you can see, they had that working and chose to disable it, presumably because they want you to manipulate paths through `URL`. (I wish the radar referenced in the commit message were public, but alas, it's not.)
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> 
>> _______________________________________________
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20170511/f3db2efd/attachment.html>