site_archiver@lists.apple.com Delivered-To: Cocoa-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=04042017; t=1504965531; bh=/9cAzJ/INZnvhoXVTfpzS+vwAmSX6hMW+hHhZeEidvw=; h=From:Content-type:MIME-version:Subject:Message-id:Date:To; b=U0BNJ9GojYNtoGJie0C9EqbrGv5uLSu+kEZAyQVEvHQ2XA6OXY0bhywDV0H2Eq7B4 nUdQtLL3H1CFH4bejm7bGAhdaFXwGPq5GmWTa71prrzev3YRyIXH5TgLJVWyEUYxGX xDzZo9Ea1cURWKS1AAzap6VLBEGwRc4s1m0wxPvqD6mvQJdDRRT0ijusoG9jJ+ZPnQ ZM6kpP/JqcNxIIzYyc7FJwrQfWDJmAZ0drbb0PLGYzPsTjP1DdylyFBn3Artj4spal oJXOpRhNL9bUDY+7TgEhLRE2WrXPoaQRWIFhuUww10n3R5SfghZYGbWEzBdpySAalh G6Kx2BCsO/KBg== The method signature is: public func enumerateBytes(_ block: (UnsafeBufferPointer<UInt8>, Data.Index, inout Bool) -> Swift.Void)
From trying out the version from NSData in Objective-C years ago, and this method’s own explanation, I know the third closure parameter controls whether to keep iterating. Instead of a pointer and a range, we have a buffer and index for the first two closure parameters. I guess the span information has just moved from the second to the first parameter. The first parameter has changed from a pointer to the start of the memory segment to a buffer enclosing the segment’s start and span. The second parameter used to represent which span of bytes within the total NSData object are modeled in the segment, now I guess it’s now the index within the Data object where the modeled segment starts. Is my guess correct?
— Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com _______________________________________________ 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/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com