I'm +1 on the proposal. Not a lot to say about it; I don't expect the community to have a passionate argument either.
Félix > Le 1 sept. 2016 à 17:37:47, Andrew Trick via swift-evolution > <[email protected]> a écrit : > > 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>> > >> On Sep 1, 2016, at 4:59 PM, Drew Crawford <[email protected] >> <mailto:[email protected]>> wrote: >> I'm possibly one of the larger users of raw byte stuff in Swift as I >> maintain an entire client/server network protocol stack in Swift userspace, >> similar in spirit to one of the examples drawn out a lot longer. Grepping >> my code produces over 200 individual uses of unsafe byte accesses. >> >> I definitely agree that the problem is significant enough to warrant a >> last-minute change. >> >> To a first approximation I agree with all the implementation choices. The >> naming, the choice of UInt8, length tracking, and debug-bounds checking are >> all correct IMO. We have been using something similar for a long time >> internally [have you been reading my code? :-) ] so I can speak from >> experience that the basic plan here is sound. >> >> One thing I would like to see is an (opt-in) release-mode-bounds-check. >> Networking is a core use case for this feature, but when you are reading >> from a socket, production is where you need a guard against out-of-bounds UB >> the most. If we can't solve it for Swift 3, affected users can write a >> wrapper to implement the boundscheck, but I think we should at very least >> take it up again for Swift 4. >> >> Drew > > In my current implementation: > https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb > > <https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb> > > The bounds checks in `copyBytes(from:)` are release mode preconditions. > > The bounds checks for `subscript`, `load(as:)`, and `storeBytes(of:as:)` are > debug only because it’s likely they occur in some loop that could be covered > by a single bounds check. By extension, the sequence iterator is only bounds > checked in debug mode. > > One possibility would be different names for the bounds checked forms of > those methods: getByte(atOffset:), setByte(atOffset:), > load(fromCheckedOffset:as:), storeBytes(of:toCheckedOffset:as:). Along with > some kind of bounds checked Iterator. > > I don’t think makes a lot of sense as generic Collection though. > Alternatively, we just have an UnsafeBoundsCheckedBytes wrapper. > > This would a good thing to experiment with in your project. We may be able to > follow-up with a Swift 4 proposal. The important thing now is to determine > whether the proposed Swift 3 design will make that wrapper difficult in any > way. > > -Andy >> On September 1, 2016 at 5:19:02 PM, Andrew Trick via swift-evolution >> ([email protected] <mailto:[email protected]>) 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>> >>> >>> Reviews are an important part of the Swift evolution process. All reviews >>> should be sent to the swift-evolution mailing list at >>> >>> <https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>> >>> >>> or, if you would like to keep your feedback private, directly to the >>> review manager. When replying, please try to keep the proposal link at >>> the top of the message: >>> >>> Proposal link: >>> <https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>> >>> >>> What goes into a review? >>> >>> The goal of the review process is to improve the proposal under review >>> through constructive criticism and, eventually, determine the direction of >>> Swift. When writing your review, here are some questions you might want to >>> answer in your review: >>> >>> * What is your evaluation of the proposal? >>> * Is the problem being addressed significant enough to warrant a >>> change to Swift? >>> * Does this proposal fit well with the feel and direction of Swift? >>> * If you have used other languages or libraries with a similar >>> feature, how do you feel that this proposal compares to those? >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >>> >>> More information about the Swift evolution process is available at >>> >>> <https://github.com/apple/swift-evolution/blob/master/process.md >>> <https://github.com/apple/swift-evolution/blob/master/process.md>> >>> >>> Thank you, >>> >>> -Dave Abrahams >>> Review Manager _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
