[swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout
jordan_rose at apple.com
Thu May 12 21:47:27 CDT 2016
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev