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

[Jacob Bandes-Storch]

This is the first version of this proposal which I've had time to read. I
like it a lot overall. If I have some more time, I may try pulling the
branch and writing some code with it to see how it feels. (If we could get
a toolchain built from the branch, that might help others review it.)

Here are a handful of minor comments:

- Naming: "bindMemory(to:capacity:)", being "verb-ish", seems incongruous
with "assumingMemoryBound(to:)" and "withMemoryRebound(to:capacity:_:)".
How about "bindingMemory(to:capacity:)" ?

- Would it be possible for "+(UnsafeRawPointer, Int) -> UnsafeRawPointer"
to accept any Integer or FixedWidthInteger, rather than only Int?

- Why allow/encourage multiple calls to bindMemory on the same RawPointer?
These APIs do a good job of making aliasing explicit by introducing data
dependencies between pointers (you can only use a typed pointer after
obtaining it from a raw pointer, and you can recover the raw pointer for
later use by deinitializing the typed pointer). So, I would think the
guidelines should prefer bindMemory to be used only once on a particular
RawPointer value.

And minor notes about the proposal itself:

- strideof(Int.self) is used in most examples, but sizeof(Int.self) appears
in one of them (the "normalLifetime()" example).

- I think there must be a mistake in this example, because pA is already
bound and bindMemory was only defined for untyped RawPointers:

    func testInitAB() {
      // Get a raw pointer to (A, B).
      let p = initAB()

      let pA = p.bindMemory(to: A.self, capacity: 1)
      printA(pA)

      printB((pA + 1).bindMemory(to: B.self, capacity: 1))   //<<< should
this be (p+1) rather than (pA+1)?
    }

Jacob

On Mon, Jul 4, 2016 at 3:32 PM, Andrew Trick via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jun 28, 2016, at 11:05 PM, Chris Lattner <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
>
>
> I've revised the proposal again based on extremely helpful feedback from
> DaveA and Jordan.
>
> This revision expands on the concept of formally binding the memory type
> that I was recently working on with Dmitri. Now we can clearly define pre
> and post conditions on memory operations and pointer casts that can be used
> to prove the type safety. The model is now simpler, more complete, and easy
> to reason about locally. This will help developers reason about correctness
> and make it easy to implement a sanitizer that verifies the type safety of
> UnsafePointer operations.
>
> Adding safety to pointer "casts" made it possible for me to actually
> simplify the allocation and initialization APIs. I think both camps,
> convenience and safety, will be happy.
>
> You can see what changed in this pull request:
> https://github.com/apple/swift-evolution/pull/408
>
> Brief summary:
>
> - Memory is dynamically bound to a single type.
>
> - All typed access to memory, whether via a typed pointer or regular
>   language construct, must be consistent with the memory's bound type
>   (the access type must be related to the bound type). Typed access
>   includes initialization, assignment, or deinitialization via a typed
>   pointer.
>
> - Memory remains bound after being deinitialized.
>
> - Memory is implicitly bound or rebound to a type by initializing it
>   via a raw pointer.
>
> - A separate API now exists for explicity binding or rebinding memory
>   to a type. This allows binding to be decoupled from initialization
>   for convenience and efficiency. It also supports safe
>   interoperability between APIs that used different, but layout
>   compatible types.
>
> - Using an API that accesses memory as a different type can now be
>   accomplished by rebinding the memory. This effectively changes the
>   type of any initialized values in memory. The compiler is still
>   permitted to assume strict aliasing for accesses on either side of
>   the operation that rebinds memory.
>
> Andy
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160704/b4ecff52/attachment.html>