On Nov 28, 2017, at 11:32 , Wim Lewis <w...@omnigroup.com> wrote: > > The only documentation of this is in the 10.9 release notes
That’s what I was thinking of — thanks for clarifying. I believe that there is one more little piece to this that’s more recent. Since (after that 10.9 change) the NSData class had to become (publicly) aware that subclasses might contain discontiguous data, the opportunity arose for Cocoa to leverage this in other scenarios, where dispatch_data_t (aka DispatchData in Swift) wasn’t involved. That’s good in general, as a performance enhancement for code that cares to enumerate the block ranges, but it happens behind the scenes. By contrast, AFAIK the only mechanism for 3rd party code to *forcibly* create NSData objects with discontiguous data buffers is via dispatch_data_t/DispatchData. For that reason, it might make more sense for Daryle to work in the DispatchData domain rather than the plain Data domain. However, as you say, there’s a bridge involving some simple hoops available if necessary. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
