> On Jun 28, 2016, at 6:54 PM, Dmitri Gribenko <[email protected]> wrote: > > On Tue, Jun 28, 2016 at 2:17 PM, Andrew Trick <[email protected]> wrote: >> >>> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko <[email protected]> wrote: >>> >>> Hi Andy, >>> >>> Everything is clear now, thank you! >>> >>> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
