> On 14 Sep 2016, at 17:08, Andrew Trick via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Sep 10, 2016, at 5:53 PM, Andrew Trick <atr...@apple.com> wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md >> >> The review period has been extended until September 14. The >> UnsafeRawBufferPointer type name is settled, but we still need to come up >> with an answer for the name of the new closure taking functions: >> >> withXyz() should normally reveal the closure argument type as Xyz. That's >> why I originally proposed UnsafeBytes as the type name. Now that we've >> decided to use the descriptive type instead we have a problem… > > I was totally wrong about this policy. In closure-taking “withXyz" functions, > “Xyz" should reveal the role of the closure argument, not its type. We do not > need to repeat type information. > > We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as > it stands. > > Note that `withRawBytes` was a strong contender, but at this time it's more > important to consistently follow the convention for using `Unsafe` in the > closure name whenever the closure argument is unsafe (e.g. you can't return > it from the closure). We may want to revisit this logic later (in some sense > Unsafe is redundant), but when we do that, we also need to reevaluate all of > our withUnsafe APIs. Furthermore, we would want to change Foundation Data's > API to be consistent. These are bigger debates that can be deferred.
An example without `Unsafe` in the function name: <https://developer.apple.com/reference/swift/string/1538904-withcstring> -- Ben _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
