[swift-evolution] [stdlib] CString.swift initializers

Dmitri Gribenko gribozavr at gmail.com
Thu Feb 25 15:02:35 CST 2016

On Thu, Feb 25, 2016 at 9:45 AM, Ben Rimmington via swift-evolution
<swift-evolution at swift.org> wrote:
> The new initializers in "CString.swift" have a precondition:
>> public init(cString: UnsafePointer<CChar>) {
>>     _precondition(cString != nil, "cString must not be nil")
>> }
>> public init?(validatingUTF8 cString: UnsafePointer<CChar>) {
>>     _precondition(cString != nil, "cString must not be nil")
>> }
> <https://github.com/apple/swift/blob/swift-3-api-guidelines/stdlib/public/core/CString.swift>
> The old `String.fromCString` function was convenient for wrapping inessential C function calls, if the `nil` coalescing operator can provide a fallback:
>> let message =
>>     String.fromCString(sqlite3_errmsg(handle)) ??
>>     String.fromCString(sqlite3_errstr(result)) ?? ""

It is a part of a long-term strategy to make UnsafePointer
non-nullable.  Nullable pointers will be modeled as optional pointers.
So this code would look like this, assuming that sqlite3 is returning
optional (nullable) pointers:

let message = sqlite3_errmsg(handle).map { String.fromCString($0) } ??
sqlite3_errstr(result).map { String.fromCString($0) }

> I also think the `validatingUTF8` argument label is misleading, because neither initializer allows ill-formed UTF-8 data to be copied.

That's what the 'validating' label is saying -- we're validating the
input and rejecting invalid inputs.

The non-failable initializer accepts ill-formed UTF-8, and repairs it.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-evolution mailing list