[swift-evolution] [Draft proposal] Faster/lower-level external String initialization
moiseev at apple.com
Fri Jan 15 17:15:19 CST 2016
> On Jan 15, 2016, at 3:06 PM, Guillaume Lessard <glessard at tffenterprises.com> wrote:
>> On 15 janv. 2016, at 15:56, Max Moiseev <moiseev at apple.com> wrote:
>> 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.
> With pointers, there some kind of nullness check either way; I would personally prefer to do it on an optional String than a probable Pointer. I guess it’s just a matter of picking a poison.
Another point is, you will have 2 checks then: one inside the function and one outside of it. Versus a single check upfront.
> As an aside, is the planned non-nilness also to become a rule for UnsafeMutablePointer?
Right now UnsafePointer and UnsafeMutablePointer are the same thing essentially. So I would expect...
> Guillaume Lessard
More information about the swift-evolution