[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