[swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout
clattner at apple.com
Fri May 20 00:21:24 CDT 2016
> On May 19, 2016, at 12:08 AM, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
> Hello Swift evolution,
> 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.
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:
- It seems like the proposal should include a discussion about that, because that’s a pretty substantial change to the programming model.
- Does TBAA for these accesses actually produce better performance in practice on any existing known use cases?
- 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).
- 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?
More information about the swift-evolution