> On May 12, 2016, at 7:47 PM, Jordan Rose via swift-dev <swift-dev@swift.org> > wrote: >> On May 12, 2016, at 18:56, Andrew Trick <atr...@apple.com >> <mailto: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.
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.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
