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

[John McCall]

> On May 12, 2016, at 7:47 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
>> On May 12, 2016, at 18:56, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> 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 common pattern).
>> 
>> In general I wanted UnsafeBytePointer to stand-in for UnsafePointer<Void> throughout the type system and handle most of the same implicit conversions. Specifically, I wanted getAnyPointerElementType to do the same thing as UnsafePointer<Void> and return an empty tuple pointee type so that the calling code could be reused. Also, I thought that supporting PointerToPointerExpr was necessary.
>> 
>> The only extra burden of doing this that I could find was that getPointerPointeePropertyDecl may return null. The only code that calls this is emitStoreToForeignErrorSlot.
>> 
>> I'm very open to alternate implementations, especially once the proposal is accepted.
> 
> I’m sorry, I got ASTContext::getPointerPointeePropertyDecl and TypeBase::getAnyPointerElementType mixed up. I’m still a little unsure that this is the right way to go, and I wonder how many uses of getAnyPointerElementType actually make sense for UnsafeBytePointer, but I see now that it’s the most incremental way to make this change.
> 
> For fun I looked through the (relatively small) set of uses for getAnyPointerElementType, and it looks like only the inout-to-pointer ones are relevant for UnsafeBytePointer. (These are the ones in lib/Sema, plus SILGen’s RValueEmitter::visitInOutToPointerExpr.) So it could be dropped as a pointer type. But it doesn’t seem to be doing any harm.

One thing Andy and I discussed is whether we could support aliasing addressors.  The answer is yes, although it will important to force a copy in cases where a non-aliasing address is required, i.e. when passing the l-value as an inout argument or when implementing materializeForSet.  An aliasing addressor would naturally return an UnsafeBytePointer value (or better yet a typed version of it).

John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160513/646b413b/attachment.html>