Probably the biggest argument is that it will make the migration more palatable. Most (??) apps today use some form of communication, and proving a better pointer solution is a big selling point. I know that my migration would have been faster and more efficient…
Rien. > On 02 Sep 2016, at 16:45, Félix Cloutier via swift-evolution > <[email protected]> wrote: > > 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> >> >>> On Sep 1, 2016, at 4:59 PM, Drew Crawford <[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 >> >> 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]) 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> >>>> >>>> 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> >>>> >>>> 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> >>>> >>>> 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> >>>> >>>> Thank you, >>>> >>>> -Dave Abrahams >>>> Review Manager _______________________________________________ >>>> 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 > > _______________________________________________ > 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
