[swift-evolution] [Draft] UnsafeRawPointer API

[Andrew Trick]

> On Jun 28, 2016, at 6:54 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> On Tue, Jun 28, 2016 at 2:17 PM, Andrew Trick <atrick at apple.com> wrote:
>> 
>>> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> 
>>> Hi Andy,
>>> 
>>> Everything is clear now, thank you!
>>> 
>>> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick <atrick at apple.com> wrote:
>>>> Initializing via a typed pointer, in addition to changing the temporal memory state, also imposes a type on the allocated memory for the entire lifetime of the memory itself, from allocation to deallocation.
>>> 
>>> I see.  Given that UnsafeMutablePoiner.initialize() has this very
>>> important difference in semantics, did you consider reflecting it in
>>> the name?  Something like '.bindTypeAndInitialize()' -- but I'm sure a
>>> better wording is possible.
>> 
>> Yes, I did consider that. I’m still open to it--maybe ‘.typedInitialize(with:). But...
>> 
>> (1) It’s awkward. The developer isn’t interested in binding the type at that point. It’s just a side effect of the way their unsafe pointer is being used.
>> 
>> (2) It would imply that the ‘.bindAndInitialize' entry point is the only way to bind the type of allocated memory. But once you have a typed pointer, it’s easy to initialize memory via a simple assignment:
>> ptrToA[0] = A() // where A is trivial
>> If ptrToA was in an uninitialized state, then that also binds the type.
> 
> It would be good to call this out in the proposal (I did not get this
> part from the clarifications that you posted this morning.)  So the
> rule is that every typed store binds the type?

Well, I’m focussing on the first initialization as a given type... I thought that explaining the rule in terms of binding allocated memory provided a simpler mental model, but it opens up questions once you try to pick it apart.

I changed the proposal so that "binding" a type is purely conceptual, not part of a formal memory model. I added the following formal rule to that section of the proposal instead:

A sequence of two memory operations to the same location violates strict aliasing under the following conditions:
- both operations access memory via a typed pointer
- the memory access types are unrelated
- at least one of the memory operations is a write
- there exists no intervening write to the same memory via a raw pointer

I updated the proposal under review with a related discussion and examples:

https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#initializing-memory-with-a-typed-pointer

-Andy