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

[Jordan Rose]

> On May 12, 2016, at 18:56, Andrew Trick <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.

Jordan

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