Now that “Raw” is introduced, also using “Unsafe” seems redundant to me. So ditch the unsafe and just go for “withRawBytes” and “withMutableRawBytes”. I expect that most code that uses this type wil already have a name indicating that it concerns a byte buffer pointer, so “withRawBytes” should give sufficient clue as to what is going on.
Rien. > On 11 Sep 2016, at 02:53, Andrew Trick via swift-evolution > <swift-evolution@swift.org> 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... > > In this code, it's obvious that a sequence of bytes is being appended to an > array. > > var buffer = [UInt8]() > withUnsafeBytes(of: &header) { > buffer += $0 > } > > In the following version, the closure argument type is obvious, which is > nice, but otherwise it's borderline unreadable, and doesn't describe what's > actually happenning. How can we tell that a sequence of bytes will be > appended? > > var buffer = [UInt8]() > withUnsafeRawBufferPointer(to: &header) { > buffer += $0 > } > > The mutable version really stretches the limits of descriptively naming > things, and still doesn't say anything about a byte sequence: > > withUnsafeMutableRawBufferPointer(to: &header) { > readHeader(into: $0) > } > > -Andy > >> On Sep 2, 2016, at 11:14 AM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> on Thu Sep 01 2016, Andrew Trick <swift-evolution@swift.org> wrote: >> >>> I’m resending this for Review Manager Dave A. because the announce list is >>> dropping his messages... >>> >>> Hello Swift community, >>> >>> The review of "UnsafeBytes" begins now and runs through September >>> 7th. This late addition to Swift 3 is a follow-up to SE-0107: >>> UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer, >>> allowing developers to continue working with collections of UInt8 values, >>> but now doing so via a type safe API. The UnsafeBytes API will not require >>> direct manipulation of raw pointers or reasoning about binding memory. >>> >>> The proposal is available here: >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md>> >>> >>> * What is your evaluation of the proposal? >> >> I strongly support inclusion of the feature, but I have issues with the >> name. It seems to me that in order to fit into the standard library, it >> should be called Unsafe[Mutable]RawBufferPointer. Each part of the name >> conveys something important, and for the same reasons we're using >> Unsafe[Mutable]BufferPointer instead of UnsafeMutableElements, we should >> stick to the scheme: >> >> - “Unsafe,” because you can break memory safety with this tool >> >> - “Raw,” because the fundamental model is that of “raw,” rather than >> “typed,” memory. >> >> - “Buffer,” because it works on a series of contiguous elements of known >> length. >> >> - “Pointer,” because it has reference semantics! When you pass one of >> these things around by value, you're not passing the bytes; you're >> passing a shared reference to the bytes. >> >>> * Is the problem being addressed significant enough to warrant a >>> change to Swift? >> >> Yes, and it fills an important funcationality gap now that we have the >> unsafe pointer model nailed down. >> >>> >>> * Does this proposal fit well with the feel and direction of Swift? >> >> Yes, except for the name. >> >>> >>> * If you have used other languages or libraries with a similar >>> feature, how do you feel that this proposal compares to those? >> >> I don't think any other language distinguishes raw from typed memory in >> this way. >> >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >> >> Enough ;-) >> >> -- >> -Dave, posting as a reviewer, not a review manager >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
