> On May 12, 2016, at 18:56, Andrew Trick <atr...@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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
