[swift-evolution] [Draft proposal] Faster/lower-level external String initialization

Max Moiseev moiseev at apple.com
Fri Jan 15 16:56:18 CST 2016

Hi Guillaume,

If we squash initializer with a default Bool = false, it will mean that the most common use case (i.e. repairing a cstring) will result in String? and will have to be (most of the time blindly) unwrapped.

As for passing nil, there are plans to make UnsafePointer non nil (and represent a nil case by Optional<UnsafePointer>.None), so an explicit nullness check is preferred before the call.


> On Jan 15, 2016, at 12:03 PM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org> wrote:
> I mostly like the proposal.
> However, it seems to me that a single constructor could do the job of both:
> init?(cString: UnsafePointer<CChar>, repairingUTF8: Bool = false)

> (and similarly for the generic constructor.)
> I agree that the static function could be called `decode(_:as:)`.
> As for the implementation, I don’t like that the `UnsafePointer<CChar>` constructors choose to crash on a null pointer, when String.fromCString politely returned nil in that situation.
> Cheers,
> Guillaume Lessard
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list