Deprecate cString on non-Darwin (#3885) #5190
Conversation
Sources/Foundation/NSStringAPI.swift
Outdated
| @@ -632,6 +632,7 @@ extension StringProtocol { | |||
|
|
|||
| /// Returns a representation of the string as a C string | |||
| /// using a given encoding. | |||
| @available(*, deprecated, message: "On platforms without Objective-C autorelease pools, use withCString instead") | |||
There was a problem hiding this comment.
There's an NSString.cString(using:) that has the same issue, FWIW
There was a problem hiding this comment.
I think that we should refer people to use String.withCString(encodedAs:_) instead of this message.
There was a problem hiding this comment.
Sure. There is one place we use this API in keyed archiver that will have to get a follow-up.
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
Sources/Foundation/NSStringAPI.swift
Outdated
| @@ -632,6 +632,7 @@ extension StringProtocol { | |||
|
|
|||
| /// Returns a representation of the string as a C string | |||
| /// using a given encoding. | |||
| @available(*, deprecated, message: "On platforms without Objective-C autorelease pools, use withCString(encodedAs:_) instead") | |||
There was a problem hiding this comment.
This one is actually safe to use though, right?
There was a problem hiding this comment.
Not unless we reimplement it to use a lifetime-limited version of the NSString cString(using:) function. Which I suppose we could do.
There was a problem hiding this comment.
I don't know if it's worth it, but it might mean less churn.
|
@swift-ci test |
|
@swift-ci test windows |
The extension on
Stringto provide a C string works well enough on Darwin, when used with anautoreleasepool { }. However, on other platforms where we have no autorelease pools, it simply leaks. Even though this API is useful on Darwin, we should deprecate it in swift-corelibs-foundation because it has repeatedly been the source of some confusing behavior.#3885