<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hey, Philippe, everyone. I've been working on implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md" class="">SE-0055: Making pointer nullability explicit</a>, and it's been going well…but only now am I realizing how much it's going to affect Foundation, and possibly CF as well. While the nullability of APIs can usually be brought over from the Foundation headers, there are a lot of places where SwiftFoundation isn't clear about its nullability requirements within its implementation. For example, NSData appears to allow replacing a range of bytes with a {NULL, 0} buffer, but the implementation currently calls directly through to _CFDataReplaceBytes, which does <i class="">not</i> accept null pointers. (And if it were annotated to, it would then try to memmove from it, which is illegal.) The fix is trivial—just check for the null pointer case (or zero length case) and use an alternate API instead—but there might be quite a few of them.<div class=""><br class=""></div><div class="">I'm planning to run through all of Foundation (and XCTest) and get their tests passing using <a href="https://github.com/apple/swift/pull/1878" class="">my branch of Swift</a>, then submit a pull request for review, to be landed in sync with the Swift change. Does that sound like the best plan to you?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jordan</div></body></html>