[se-0405] rename String.init(validatingUTF8:)

[glessard]

API renaming from SE-0405, namely:

public init?(validatingUTF8 cString: UnsafePointer<CChar>)

renamed to

public init?(validatingCString nullTerminatedUTF8: UnsafePointer<CChar>)

We expected to do a symbol switch using @_silgen_name, but that cannot be done at the moment. (See #68433). The most compact alternative is this, where the renamed initializer uses the deprecated symbol -- sadly resulting in a deprecation warning when building the standard library.

Follow-up to #68419, rdar://114999766

[glessard]

@swift-ci please smoke test

[glessard]

@swift-ci please smoke test

[benrimmington]

The existing init(cString:) has overloads for UInt8 code units:

extension String {
  public init(cString nullTerminatedUTF8: UnsafePointer<CChar>)
  public init(cString nullTerminatedUTF8: UnsafePointer<UInt8>)
  public init(cString nullTerminatedUTF8: [CChar])
  public init(cString nullTerminatedUTF8: [UInt8])
}

@available(*, deprecated)
extension String {
  public init(cString nullTerminatedUTF8: inout CChar)
  public init(cString nullTerminatedUTF8: inout UInt8)
  public init(cString nullTerminatedUTF8: String)
}

• Should init(validatingCString:) have the same overloads?

• Should CChar be changed to CSignedChar or Int8?

[glessard]

The decision to always typealias CChar to Int8 is documented here: https://github.com/apple/swift/blob/main/docs/HowSwiftImportsCAPIs.md#fundamental-types
It is not well explained, but at least the source has authority.

I have been wondering about the init(cString:) initializer. The CChar version is a StringProtocol requirement, and SubString has that version. The UInt8 version was added to String, but it's not clear why not to SubString or, for that matter, StringProtocol. I suspect it may have been an oversight -- the String version is needed much more often.

This being said, in the spirit of SE-0324, it seems like we should have UInt8 and Int8 versions of C string interop functions in general.

[glessard]

It would seem preferable to point the ABI entry point to String.init?(validatingCString:), but renaming initializers isn't supported by @_silgen_name. This solution will cause a warning when compiling the stdlib in Swift 6.

[glessard]

@swift-ci please test

[natecook1000]

Looks great! Would be nice to take this opportunity to give that initializer docs, too 👍🏻

[natecook1000]

Can we more or less duplicate the docs for the other validatingCString initializer here?

[glessard]

Good thought. These are stop-gap api that should be removed once pointer conversions can be restricted, but the time horizon is so long that it makes sense to document them until then. I should probably have done that when adding them last year.

[glessard]

I will do the documentation update you suggest in a separate PR.

[glessard]

Addressing the documentation issues in #71224