Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 20, 2016, at 7:56 AM, Chris Lattner wrote: > On May 12, 2016, at 4:03 PM, John McCall via swift-dev > wrote: > On May 12, 2016, at 3:21 PM, Joe Groff wrote: > On May 12, 2016, at 11:21 AM, John McCall wrote: > >> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-d

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

On May 12, 2016, at 4:03 PM, John McCall via swift-dev wrote: >>> On May 12, 2016, at 3:21 PM, Joe Groff wrote: On May 12, 2016, at 11:21 AM, John McCall wrote: > On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev > wrote: > On May 12, 2016, at 10:44, Joe Groff w

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 4:03 PM, John McCall via swift-dev > wrote: > >> On May 12, 2016, at 3:21 PM, Joe Groff wrote: >>> On May 12, 2016, at 11:21 AM, John McCall wrote: >>> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev wrote: > On May 12, 2016, at 10:44, Joe Groff

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 7:47 PM, Jordan Rose via swift-dev > wrote: >> On May 12, 2016, at 18:56, Andrew Trick > > wrote: >> >>> - What was the thought behind putting UnsafeBytePointer in PointerTypeKind? >>> OpaquePointer isn’t there, and I’m concerned about places that

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 18:56, Andrew Trick wrote: > >> - What was the thought behind putting UnsafeBytePointer in PointerTypeKind? >> OpaquePointer isn’t there, and I’m concerned about places that test if >> something’s a pointer by checking that the pointee type is non-null (by far >> the com

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 18:34, Andrew Trick wrote: > >> - On the flip side, I think we do need to preserve the ability to >> reference-cast in order to send Objective-C messages, at least for now. I >> don’t know how I want to expose that to users, though. (In general it’s >> probably worth see

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 9:27 AM, Jordan Rose wrote: > > Thoughts on the diff: https://github.com/atrick/swift/tree/unsafeptr_convert > - What was the thought behind putting UnsafeBytePointer in PointerTypeKind? > OpaquePointer isn’t ther

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 9:27 AM, Jordan Rose wrote: > > On the model itself: Responding to your feedback on the model (thanks!). https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst With

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 3:21 PM, Joe Groff wrote: >> On May 12, 2016, at 11:21 AM, John McCall wrote: >> >>> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev >>> wrote: On May 12, 2016, at 10:44, Joe Groff wrote: > On May 12, 2016, at 9:27 AM, Jordan Rose via swift-d

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 11:21 AM, John McCall wrote: > >> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev >> wrote: >>> On May 12, 2016, at 10:44, Joe Groff wrote: >>> >>> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev wrote: - I’m uncomfortable wi

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 11:21 AM, John McCall via swift-dev > wrote: > > Well, we can say "A program has undefined behavior if it does X or Y", or we > can say "A program which does X or Y lacks type safety". In all cases we are > referring to a concept defined elsewhere. If we say "undefined

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev > wrote: >> On May 12, 2016, at 10:44, Joe Groff > > wrote: >> >> >>> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev >> > wrote: >>> >>> >>> - I’m uncomfortable with using th

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 10:44, Joe Groff wrote: > > >> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev > > wrote: >> >> >> - I’m uncomfortable with using the term “undefined behavior” as if it’s >> universally understood. Up until now we haven't formally had

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev > wrote: > > > - I’m uncomfortable with using the term “undefined behavior” as if it’s > universally understood. Up until now we haven't formally had that notion in > Swift, just “type safety” and “memory safety” and “invariant-preserv