[swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

Andrew Trick atrick at apple.com
Tue Jul 12 01:59:40 CDT 2016


I merged the last of my edits to this proposal (see the PR below), if anyone it interested in seeing where things ended up and doing last minute reviews.

https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md

-Andy

> On Jul 10, 2016, at 6:41 AM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Jul 4, 2016, at 5:32 PM, Andrew Trick via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Jun 28, 2016, at 11:05 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through July 4, 2016. The proposal is available here:
>>> 
>>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>
>> 
>> 
> 
> I'm revising this proposal based on last week's feedback. A few of the
> additive APIs are removed and a number of UnsafePointer and
> UnsafeRawPointer methods are renamed.
> 
> Here is a PR for the revision. Note that the examples in the proposal
> text still need to be updated:
> https://github.com/apple/swift-evolution/pull/420 <https://github.com/apple/swift-evolution/pull/420>
> 
> I updated the short-form summary of the API:
> https://github.com/atrick/swift-evolution/blob/3122ace9d2fb55072ebd7395c7353fcbf497318a/proposals/0107-unsaferawpointer.md#full-unsaferawpointer-api <https://github.com/atrick/swift-evolution/blob/3122ace9d2fb55072ebd7395c7353fcbf497318a/proposals/0107-unsaferawpointer.md#full-unsaferawpointer-api>
> 
> The full UnsafeRawPointer API with doc comments is here:
> https://github.com/atrick/swift/blob/22e3a2885e4236888ec447a7148acf633d8544f5/stdlib/public/core/UnsafeRawPointer.swift.gyb <https://github.com/atrick/swift/blob/22e3a2885e4236888ec447a7148acf633d8544f5/stdlib/public/core/UnsafeRawPointer.swift.gyb>
> 
> The UnsafePointer and UnsafeRawPointer changes are on this branch:
> https://github.com/atrick/swift/commits/rawptr <https://github.com/atrick/swift/commits/rawptr>
> 
> If you wish to comment line-by-line on the detailed docs or
> implementation, you can do so here:
> https://github.com/apple/swift/pull/3437 <https://github.com/apple/swift/pull/3437>
> 
> --- 
> I should preemptively answer the question "why do UnsafeRawPointer
> methods take an explicit type argument when it can be inferred?". Such
> as:
> 
>   rawPtr.initializeMemory(as: Int.self, ...)
> 
> These methods don't simply operate on values of some type, they
> actively bind memory to that type. At the point of use, that type
> needs to be explicit to convey that fact. It's important for
> readability, comprehension, and correctness. We cannot rely on type
> inferrence on some expression which can change without the original
> author's intervention resulting in subtle miscompiles.
> 
> ---
> The only concern I have about this version of the proposal is this method name: 
> 
>   func copyBytes(from: UnsafeRawPointer, count: Int)
> 
> because `count` usually refers to a number of values. I think it should be:
> 
>   func copy(bytes: Int, from: UnsafeRawPointer)
> 
> -Andy
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/26267eac/attachment.html>


More information about the swift-evolution mailing list