<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 19, 2016, at 10:21 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On May 19, 2016, at 12:08 AM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hello Swift evolution,<br class=""><br class="">I'm sending this proposal out again for another round of RFC. The first round did not get much specific feedback, and nothing has fundamentally changed. In this updated version I beefed up the explanation a bit and clarified the language.<br class=""></blockquote><br class="">Hi Andy,<br class=""><br class="">I think this is a reasonable proposal. It seems like the real win here is to be able to define TBAA rules for Unsafe[Mutable]Pointer references, instead of having to treat them *all* conservatively (something I’m generally supportive of). A few questions/observations:<br class=""><br class="">- It seems like the proposal should include a discussion about that, because that’s a pretty substantial change to the programming model.<br class=""></div></div></blockquote><div><br class=""></div><div>Right, although we don’t have a formal spec, I thought it was worthwhile to capture Swift’s notion of TBAA rules for the sake of discussion. This design document is based on today’s reality, not the proposed change:</div><a href="https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst" class="">https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst</a></div><div>(and there’s an even lower-level SIL description)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- Does TBAA for these accesses actually produce better performance in practice on any existing known use cases?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes, but I’d have to rerun the numbers. Under the hood we do a lot of conversion to UnsafePointer. My feeling is that UnsafePointer is intended to be a tool for building low-level, high-performance data structures.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- Would it be possible for tools like UBSAN to catch violations of this? I’m not familiar with what ubsan does for C TBAA violations (if anything).<br class=""></div></div></blockquote><div><br class=""></div><div>Yes, we definitely want to be able to feed TBAA information to a sanitizer. That’s a big part of my argument for clarifying the rules for safe/unsafe operation. But I think it’s quite different from the things that UBSAN checks now. </div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- It isn’t clear to me why it is important to change how "void*” is imported. Since you can’t deference an UnsafePointer<Void> anyway, why does it matter for this proposal?<br class=""></div></div></blockquote><div><br class=""></div><div>Briefly, it’s not essential for the TBAA story. That has to do with allowing safe casts to be inferred and implicit, while type-unsafe casts require explicit conversion. Also, the UnsafeMutablePointer API is nonsense with a Void Pointee.</div><div><br class=""></div><div>Whether it’s part of this proposal, or done later really depends on how we want to handle migration. Here’s how it plays out:</div><div>- I got strong feedback that I should first be able to prevent UnsafePointer<T> to UnsafePointer<U> coercion before introducing a new aliasing pointer type</div><div>- Wherever users are attempting that conversion, some additional cast will need to be introduced</div><div>- A lot of UnsafePointer conversion is actually safe conversion to UnsafePointer<Void>, it would be a shame to penalize all that code</div><div>- Changing the import type of UnsafePointer<Void> allows that code to be migrated without introducing useless casts</div><div><br class=""></div><div>It might be nice to introduce UsafeBytePointer first without restricting UnsafePointer conversion, then there’s no immediate need to change the import type. Leaving the API in that state just don’t make as much sense conceptually. I also actually tried this and was not able to implement all the expected implicit pointer conversions without running into ambiguous overloads. I think eliminating the UnsafePointer<T> conversion nicely simplifies the type checker’s job.</div><div><br class=""></div><div>-Andy</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">-Chris<br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>