Bring NSString functions to String

Eric_Blachere · May 8, 2017, 4:39pm

Hello,

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 ;)

Thanks,
Eric

Brent_Royal-Gordon · May 10, 2017, 8:52am

Unfortunately, it seems like the decision not to include these methods on String was quite deliberate.

Here's the revision where that happened: <Drop APIs from NSPathUtilities.h on String · apple/swift@1f2390f · GitHub; 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.)

···

On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev <swift-corelibs-dev@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 ;)

--
Brent Royal-Gordon
Architechies

Eric_Blachere · May 10, 2017, 9:45am

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@architechies.com>:

> On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev < > swift-corelibs-dev@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: <Apple · GitHub
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

Andrey_Fidrya · May 10, 2017, 11:19am

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.
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@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@architechies.com <mailto:brent@architechies.com>>:
> On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@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: <Drop APIs from NSPathUtilities.h on String · apple/swift@1f2390f · GitHub; 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Tony_Parker · May 11, 2017, 9:05pm

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

···

On May 10, 2017, at 4:19 AM, Andrey Fidrya via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

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@swift.org <mailto:swift-corelibs-dev@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@architechies.com <mailto:brent@architechies.com>>:
> On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@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: <Drop APIs from NSPathUtilities.h on String · apple/swift@1f2390f · GitHub; 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@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Andrey_Fidrya · May 12, 2017, 12:17am

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?

OS X, HFS+. The app reconstructed account names from filenames by dropping file extensions. The filename was converted to NFC form once then NSString's methods were used for manipulating the filename. These methods weren't denormalizing the string. After switching to URL the resulting account names started triggering warnings about invalid characters in them ('й' should have been a valid character, but after denormalizing it was no longer found).

- Andrey

···

On 12 May 2017, at 00:05, Tony Parker <anthony.parker@apple.com> wrote:

On May 10, 2017, at 4:19 AM, Andrey Fidrya via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

- 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@swift.org <mailto:swift-corelibs-dev@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@architechies.com <mailto:brent@architechies.com>>:
> On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@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: <Drop APIs from NSPathUtilities.h on String · apple/swift@1f2390f · GitHub; 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@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Tony_Parker · May 12, 2017, 4:24pm

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?

OS X, HFS+. The app reconstructed account names from filenames by dropping file extensions. The filename was converted to NFC form once then NSString's methods were used for manipulating the filename. These methods weren't denormalizing the string. After switching to URL the resulting account names started triggering warnings about invalid characters in them ('й' should have been a valid character, but after denormalizing it was no longer found).

- Andrey

Thanks Andrey. Since this is on Mac, I filed a bug for you in our internal system to follow up on this (32156825).

- Tony

···

On May 11, 2017, at 5:17 PM, Andrey Fidrya <af@zabiyaka.com> wrote:

On 12 May 2017, at 00:05, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:

On May 10, 2017, at 4:19 AM, Andrey Fidrya via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

- 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@swift.org <mailto:swift-corelibs-dev@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@architechies.com <mailto:brent@architechies.com>>:
> On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@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: <Drop APIs from NSPathUtilities.h on String · apple/swift@1f2390f · GitHub; 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@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev